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La sexta edición de Análisis y diseño de sistemas, de Kendall y Kendall, contiene muchas ca¬ 
racterísticas nuevas y actualizadas, como las siguientes: 

8 Nuevas prácticas y valores esenciales de la programación extrema (XP). 

• Más de 65 Oportunidades de consultaría, que incluyen una gran cantidad de casos 
breves dirigidos al diseño para comercio electrónico, programación extrema y 
modelado con UML. 

8 Mayor énfasis en el diseño basado en la Web. 

8 Nuevos enfoques para diseñar sitios Web de comercio electrónico. 

9 Una mayor cobertura del diseño de interfaces gráficas de usuario (GUI). 

8 Nuevas alternativas para la administración de proyectos con la metodología de la 
programación extrema. 

• Nuevos enfoques de diseño para las tecnologías inalámbricas, ERP y sistemas 
basados en Web. 

8 Un tratamiento más profundo de XML. 

8 Mayor cobertura del diseño para intranets y extranets, incluyendo técnicas sencillas 
de navegación en pantalla. 

9 Un capítulo nuevo orientado a objetos que incluye modelado con UML. 

8 Una explicación más detallada sobre cómo decidir entre el software comercial 
[COTS] o subcontratado con un ASP. 

9 Nueva cobertura sobre la implementación de medidas de seguridad y privacidad en 
el sitio Web, como firewalls, políticas de privacidad corporativas, PKI, SSL, SET, 

VPN, filtros URL y filtrado del correo electrónico. 

9 Nuevas técnicas para aplicar las prácticas esenciales de la programación extrema y 
métodos ágiles para desarrollar sistemas orientados al cliente. 

8 Un tratamiento más amplio del software para monitorear el tráfico en la Web, 
realizar perfiles de la audiencia y promover sitios Web corporativos para garantizar 
la eficacia de los nuevos sistemas de comercio electrónico. 

8 Nueva cobertura de la metodología Seis Sigma para mejorar la calidad del diseño 
de software y sistemas. 

9 Caso de la CPU continuo y actualizado, en el cual se utiliza Visible Analyst y 
Microsoft Access. 

8 HyperCase 2.5 actualizado, simulación gráfica de una organización en la Web que 
permite a los estudiantes aplicar sus conocimientos. 

Análisis y diseño de sistemas, de Kendall y Kendall, es un libro que presenta de manera pre¬ 
cisa los métodos, herramientas y técnicas de desarrollo de sistemas con un toque humorístico 
y fácil de entender. 


CARACTERÍSTICAS DE DISEÑO 

Se dio una apariencia estilizada a las figuras con el propósito de ayudar a los estudiantes a 
comprender con más facilidad el contenido de las mismas. 






Se utilizan formularios impresos a lo largo de 
todo el libro con la idea de mostrar el diseño de en¬ 
tradas y salidas, así como el diseño de cuestionarios. 
Aunque la computarización de los procesos manuales 
es una meta para la mayoría de las organizaciones, 
gran parte de la captura de datos aún se realiza en 
formularios impresos. El perfeccionamiento del diseño 
de formularios permite a los analistas garantizar la 
captura (entrada y salida) de datos precisa y completa. 
El uso de mejores formularios también contribuye a 
agilizar los nuevos flujos de trabajo internos resul¬ 
tantes de las recientes aplicaciones automatizadas 
"negocio a consumidor" (B2C) que se emplean para 
el comercio electrónico en la Web. 



Las pantallas de computadora ilustran caracte¬ 
rísticas importantes del software muy útiles para el 
analista. En este ejemplo se muestra la manera de de¬ 
tectar vínculos rotos (o modificados) en un sitio Web 
mediante un paquete como Microsoft Visio. Imáge¬ 
nes de pantalla, tal como las verá en su computado¬ 
ra, presentan aspectos importantes del diseño. Los 
analistas buscan constantemente cómo mejorar la 
apariencia de las pantallas (salidas de programa) y las 
páginas Web que diseñan; todo en aras de facilitar la 
labor del usuario. 

Se emplean diagramas conceptuales para presentar las diversas herramientas con que 
cuentan los analistas de sistemas. En este ejemplo se demuestran las diferencias entre los 

diagramas lógicos de flujo de datos y los diagramas 

Plsgraa» de [luja «fe datan lógico 

físicos de flujo de datos. También se ilustran otras 
herramientas importantes, como los diagramas de 
entidad-relación, los diagramas de estructura y el es¬ 
pañol estructurado. 

Las tablas se utilizan en aquellos casos en que 
una lista importante requiere atención especial, o 
cuando la información se tiene que organizar o clasi¬ 
ficar. Asimismo, se emplean para complementar la 
comprensión del lector de la manera en que se orga¬ 
niza el material en el texto general. Las tablas consti¬ 
tuyen una opción útil para los analistas cuando desean organizar cifras y texto con el propó¬ 
sito de reflejar una "visión global" significativa. 




El siguiente ejemplo de una tabla, del capítulo 3, muestra la forma en que los analistas 
pueden refinar sus planes de actividades de análisis dividiendo las actividades en tareas más 
pequeñas y calculando el tiempo que les tomará realizarlas. La filosofía que sustenta nues¬ 
tro libro consiste en que el análisis y diseño de siste¬ 


mas es un proceso que integra el uso de diversas he¬ 
rramientas con el talento individual del analista de 
sistemas para refinar sistemáticamente los negocios 
mediante la implementación o modificación de siste¬ 
mas de información computarizados. Los analistas de 
sistemas pueden progresar en sus trabajos asumiendo 
nuevos retos de tecnología de la información y man¬ 
teniéndose actualizados en su profesión mediante la 
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aplicación de nuevas técnicas y herramientas. 
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REPASO DE LA SEXTA EDICION 


k 


El análisis y diseño de sistemas se imparte por lo general en uno o dos semestres. Nuestro li¬ 
bro funciona en ambos casos. El texto es apropiado para estudiantes universitarios o de pos¬ 
grado. El nivel y duración del curso puede variar y complementarse con proyectos reales, 
HyperCase u otros materiales disponibles en la sección de recursos para el profesor del sitio 
Web de esta obra. 

El texto se divide en cinco partes principales: Fundamentos del análisis de sistemas 
[parte I), Análisis de los requerimientos de información [parte II), El proceso de análi¬ 
sis (parte III), Aspectos esenciales del diseño [parte IV) e Ingeniería e implementación de 
software [parte V). 

La parte I (capítulos 1-3) pone énfasis en los aspectos básicos que los es¬ 
tudiantes deben conocer sobre las actividades de un analista; cuál es la fun¬ 
ción de los diversos sistemas de información en una organización, como las 
L computadoras portátiles, las tecnologías inalámbricas y los sistemas ERP; cómo 

determinar si vale la pena emprender un proyecto de sistemas; nueva cober¬ 
tura de administración de proyectos de comercio electrónico, y cómo manejar un proyecto 
de sistemas con herramientas de software especiales. Contiene material actualizado sobre 
equipos y organizaciones virtuales. Se presentan técnicas para dibujar diagramas de entidad- 
relación y diagramas de flujo de datos de contexto para los casos en que se entra en contac¬ 
to por primera vez con una organización. El capítulo 3 incluye material nuevo para explicar 
la manera en que un enfoque alternativo denominado programación extrema (XP) equili¬ 
bra los objetivos para manejar el proceso de análisis y diseño. También se presentan los tres 
papeles del analista de sistemas, como consultor, experto en apoyo técnico y agente de cam¬ 
bio, y se incorporan ideas actualizadas sobre aspectos éticos y lincamientos profesionales 
para desempeñar el papel de consultor de sistemas. 

■ k La parte II (capítulos 4-6) resalta 

el uso de metodologías sistemáticas y 
estructuradas para realizar el análisis 
L' ¿"¿L de los requerimientos de información. 

La aplicación de un análisis contribuye 
a que el analista garantice que se está enfocando en el 
problema correcto previo al diseño del sistema. El 
capítulo 4 presenta un grupo de métodos interacti¬ 
vos, entre ellos las entrevistas, el diseño conjunto de 

aplicaciones (JAD) y la elaboración de cuestionarios. El capítulo 5 incluye un grupo de mé¬ 
todos discretos para determinar los requerimientos de información de los usuarios. Entre 
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estos métodos se cuentan el muestreo, la revisión de datos impresos y archivados, y el estudio 
del comportamiento de los encargados de la toma de decisiones y de su entorno físico. El 
capítulo 6 presenta una cobertura especialmente novedosa sobre la elaboración de prototi¬ 
pos como otra técnica de recopilación de datos, que da al analista la posibilidad de resolver 
el problema preciso al involucrar a los usuarios desde el principio. Este capítulo también in¬ 
cluye material sobre el desarrollo rápido de aplicaciones (RAD). El material nuevo permite 
a los estudiantes comprender el enfoque de programación extrema (XP) para el desarrollo 
de sistemas. Se explican las prácticas esenciales que distinguen a XP de otras metodologías. 
Además, se presentan los valores fundamentales para XP y el modelado ágil. 

En la parte DI (capítulos 7-10) se detalla el proceso de análisis. Toma co- 
mo base las dos partes anteriores para llevar al estudiante al análisis de los flu- 
jos d e datos y de las decisiones estructuradas y semiestructuradas. Ofrece ex- 
• A i plicaciones paso a paso sobre el uso de técnicas estructuradas para dibujar 
diagramas de flujo de datos (DFDs). El capítulo 7 muestra cómo crear diagra¬ 
mas hijos; cómo desarrollar diagramas lógicos y físicos de flujo de datos, y cómo particionar 
diagramas de flujo de datos. Incluye una sección actualizada que explica el enfoque orienta¬ 
do a objetos de los casos de uso y los diagramas de flujo de datos. El enfoque orientado a ob¬ 
jetos del capítulo 8 presenta material sobre el depósito de datos y el balanceo vertical de 
diagramas de flujo de datos. El capítulo 8 también presenta una amplia cobertura del Len¬ 
guaje de Marcado Extensible (XML) y demuestra cómo usar los diccionarios de datos para 
crear XML. El capítulo 9 contiene material sobre el desarrollo de especificaciones de pro¬ 
cesos. Una explicación de las especificaciones lógicas y físicas de procesos ilustra cómo uti¬ 
lizarlas en el balanceo horizontal. 

La parte El también describe cómo diagramar decisiones estructuradas a través del es¬ 
pañol estructurado, tablas de decisión y árboles de decisión. Asimismo, se presentan las tec¬ 
nologías de actualización automática. 

El capítulo 10 describe diversos métodos para pronosticar costos y beneficios, los cua¬ 
les son indispensables para decidir la compra de software y hardware. El material nuevo del 
capítulo 10 ayuda a los estudiantes a evaluar las ventajas y desventajas entre crear software 
personalizado, comprar software comercial (COTS) o subcontratar el software con un pro¬ 
veedor de servicios de aplicaciones (ASP). Asimismo, el material nuevo muestra a los estu¬ 
diantes cómo ayudar a los encargados de la toma de decisiones a seleccionar el software de 
apoyo a la toma de decisiones, sistemas de recomendación y el uso de redes neurales. El ca¬ 
pítulo 10 también guía a los estudiantes a través de la presentación y redacción profesional 
de una propuesta eficaz de sistemas, que incluya cifras y gráficas para comunicarse con los 


A. En la parte IV (capítulos 11-15) se explican los fundamentos del diseño. 

i''}'" ,.- Se empieza por el diseño de la salida, puesto que muchos expertos consideran 

que los sistemas deben orientarse a la salida. El diseño de los formularios ba- 
pKkíi.- sados en la Web se analiza con detalle. Se pone especial atención en relacionar 
el método de salida con el contenido, el efecto de la salida sobre los usuarios 
y en el diseño de formularios y pantallas eficaces. El capítulo 11 compara las ventajas y des¬ 
ventajas de la salida, incluyendo las pantallas de informes en la Web, audio, CD-ROM, DVD 
y la salida electrónica como el correo electrónico, los faxes y los boletines electrónicos. Se 
resalta el diseño de un sitio Web dedicado al comercio electrónico, y se describe la produc¬ 
ción de salida y de XML. El capítulo 12 incluye material novedoso sobre el diseño de 

formularios de entrada de datos basados en la Web, A . 

así como de otros formularios electrónicos. También 

se presenta el diseño de formularios asistido por §S SsSijiisbÜI 

computadora. I .. .... 3 

El capítulo 12 también ofrece una amplia cober- ¡|“ 

tura del diseño de sitios Web, con lincamientos para :.. 

determinar cuándo deben los diseñadores incorporar C! ... . . —— 7 ~'~" 

vídeo, audio y animación en los diseños de sitios Web. |i|£ . ¡ . 

Se explican los usos de las tecnologías de actualización *•— ks * 
y recepción automática de la Web para diseñar la salí- ¿.¿¿«a 



Cusíom* dDB Trtd<4itni Qt V/QH.t 
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da. Se dedica más espacio a describir cómo crear gráficos apropiados para sitios Web corpora¬ 
tivos y a diseñar elementos de navegación en pantalla eficaces para usuarios de sitios Web. 

También hay una mayor cobertura del diseño de páginas para intranets y extrañéis. Se 
incluyó una explicación de las restricciones a la integridad de bases de datos y de la manera 
en que interactúa el usuario con la computadora y cómo diseñar una interfaz apropiada. En 
esta parte IV se menciona la importancia de la retro alimentación del usuario. También se 
resalta el diseño de procedimientos precisos para la entrada de datos que aprovechen al má¬ 
ximo las capacidades humanas y de la computadora con el fin de garantizar la entrada de 
datos de calidad. 

El capítulo 13 demuestra cómo utilizar los diagramas de entidad-relación para determi¬ 
nar claves de registros, así como para ofrecer lincamientos para el diseño de relaciones ar¬ 
chivo/base de datos. Se muestra a los estudiantes la importancia del diseño de bases de da¬ 
tos para conseguir la máxima utilidad del sistema, y la manera en que los usuarios emplean 
las bases de datos. El capítulo 14 presenta material sobre el diseño de elementos sencillos de 
navegación en pantalla para los visitantes de sitios Web. También ofrece material actualiza¬ 
do en relación con aspectos importantes de la extracción y el almacenamiento de datos. Asi¬ 
mismo, se incluyen enfoques novedosos para realizar búsquedas en la Web. Se hace énfasis 
en el material sobre el diseño de GUIs y se proporcionan enfoques recientes para diseñar 
cuadros de diálogo. El capítulo 14 estructura nuevas consideraciones especializadas de dise¬ 
ño para sitios Web dedicados al comercio electrónico. También contiene explicaciones más 
detalladas sobre la generación de consultas que permitan a los usuarios realizar búsquedas 
en la Web. En el capítulo 15 se presenta material actualizado acerca de la administración de 
la cadena de abastecimiento mediante el diseño eficaz de sistemas de comercio electrónico 


negocio a negocio (B2B). 

La parte V (capítulos 16-18) introduce a los estudiantes en la ingeniería 
'''i' de software estructurada y en técnicas de documentación como medios para 
implementar un sistema de calidad. El capítulo 16 ofrece nuevo material en 
la adopción de la metodología Seis Sigma para alcanzar la calidad en el dise¬ 
ño de software y sistemas. El capítulo 16 también incluye una sección acerca 
de los importantes conceptos de generación de código y reingeniería de diseño. Asimismo, 
explicamos los desarrollos en técnicas estructuradas y enseñamos a los estudiantes cuáles 
técnicas son apropiadas para cada situación específica. 

El material sobre diagramas de estructura contiene detalles sobre la manera de utilizar 
diagramas de flujo de datos para dibujar diagramas de estructura. Además, se incluye mate¬ 
rial sobre seguridad de sistemas y firewalh. La prueba, auditoría y mantenimiento de sis¬ 
temas se explica en el contexto de la administración de la calidad total. El capítulo 17 pre¬ 
senta herramientas novedosas para el modelado de redes, lo cual se puede realizar con 
herramientas populares como Microsoft Visio. Asimismo, contiene una descripción sobre el 
software de grupo. La parte V también introduce al estudiante al diseño de sistemas clien¬ 
te/servidor, sistemas distribuidos y múltiples sistemas inalámbricos, como WLANs, redes 
Wi-Fi y redes Bluetooth. 

Se ofrece material relacionado con la seguridad y la privacidad al diseñar aplicaciones 
de comercio electrónico. También se incluye una mayor cobertura sobre seguridad, en espe¬ 
cial acerca d efirewalh, puertas de enlace, infraestructura de clave pública (PKI), traducción 
electrónica segura (SET), capas de sockets seguras (SSL), software de protección antivirus, 
productos de filtrado URL, productos de filtrado de correo electrónico y redes privadas vir¬ 
tuales (VPNs). Además, se presentan temas actuales de interés para diseñadores de aplica¬ 
ciones de comercio electrónico, como el desarrollo de perfiles de la audiencia y el desarrollo 
y publicación de políticas de privacidad corporativa. 

En esta sección se incluye una cobertura actualizada de la manera en que el analista 
puede promover y a continuación monitorear un sitio Web corporativo; también se presen¬ 
ta el monitoreo de actividades en la Web, la promoción de sitios Web, el análisis del tráfico 
en la Web y la generación de perfiles de la audiencia, con el propósito de garantizar la efica¬ 
cia de nuevos sistemas de comercio electrónico. Asimismo, se cubren sistemáticamente téc¬ 
nicas para evaluar los proyectos terminados de sistemas de información. 
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La parte V concluye con el capítulo 18, rela¬ 
tivo al análisis y diseño de sistemas orientados a 
objetos, que contiene una nueva y detallada sec¬ 
ción sobre el uso del Lenguaje de Modelado Uni¬ 
ficado (UML). Hay una nueva explicación sobre 
el modelo de casos de uso, la creación de diagra¬ 
mas de modelo de clases con UML, la creación de 
diagramas de generalización/especialización, es¬ 
cenarios de casos de uso y diagramas de activida¬ 
des. Este capítulo demuestra, mediante diversos 
ejemplos y secciones Oportunidades de consul- 
toría, cómo utilizar un enfoque orientado a objetos. Nuevas Oportunidades de consultoría, 
diagramas y problemas hacen posible que los estudiantes aprendan y utilicen UML para 
modelar sistemas desde una perspectiva orientada a objetos. 

La sexta edición contiene un Glosario de términos y una lista independiente de Siglas 
que se utilizan en el libro y en el campo del análisis y diseño de sistemas. 

CARACTERÍSTICAS PEDAGÓGICAS 

Los capítulos de la sexta edición contienen: 

8 Objetivos de aprendizaje al principio de cada capítulo. 

8 Resúmenes que enlazan los puntos notables de cada capítulo, al mismo tiempo que 
ofrecen una excelente fuente de revisión para los exámenes. 

18 Palabras y frases clave. 

• Preguntas de repaso. 

8 Problemas. 

9 Proyectos de grupo que ayudan a los estudiantes a trabajar en conjunto en un 
equipo de sistemas, con el propósito de solucionar problemas importantes que 
se resuelven mejor a través de la interacción en grupo. 

8 Oportunidades de consultoría —más de 65 minicasos a lo largo de todo el libro. 

8 Experiencias con HyperCase. 

8 Episodios de los casos de la CPU —partes de un caso continuo eslabonado a lo 
largo de todo el libro. 




OPORTUNIDADES DE CONSULTORÍA 

La sexta edición contiene más de 65 Oportunidades de consultoría, muchas 
de las cuales abordan nuevos temas que han surgido en el campo, como el 
diseño de aplicaciones de comercio electrónico para la Web, el software co¬ 
mercial (COTS) y el uso de UML 


para modelar sistemas de información desde una 
perspectiva orientada a objetos. Las Oportunidades de 
consultoría se pueden aprovechar para propiciar 
debates en clase, asignarlas como tareas o como pre¬ 
guntas de examen para resolver en casa. Puesto que 
no todos los sistemas son proyectos que duran de dos 
a tres años, nuestro libro contiene muchas Oportu¬ 
nidades de consultoría que se pueden solucionar rá¬ 
pidamente en 20 o 30 minutos de debate en grupo o 
de manera individual. Estos minicasos, escritos de 
una manera humorística para hacer ameno el mate¬ 
rial, requieren que el estudiante sintetice lo que haya 
aprendido hasta ese punto del curso, que madure en 



lo concerniente a sus criterios éticos y profesionales, y que explique las razones que lo con¬ 


dujeron a tomar sus decisiones de sistemas. 
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EXPERIENCIAS CON HYPERCASE 

En cada capítulo hay Experiencias con HyperCase, las cuales plantean ejerci¬ 
cios que constituyen un reto para los estudiantes. HyperCase 2.5 se encuen¬ 
tra ahora disponible en la Web. Hy¬ 
perCase contiene ahora problemas organizacionales 
actualizados que representan sistemas tecnológicos 
de vanguardia. HyperCase es una oganización vir¬ 
tual que da a los estudiantes la oportunidad de 
adentrarse de inmediato en la vida organizacional. 

Los estudiantes entrevistarán gente, observarán en¬ 
tornos de oficina, analizarán sus prototipos y revisarán 
la documentación de sus sistemas existentes. Hy¬ 
perCase 2.5 es un software interactivo basado en la 
Web que presenta una organización denominada 
Maple Ridge Engineering (MRE) en un entorno de 
gráficos tridimensionales a todo color. HyperCase 
da a los profesores la posibilidad de plantear el aná¬ 
lisis de sistemas y la clase de diseño con material 
multimedia interesante. Vigilando con atención el 
uso del tiempo y manejando múltiples métodos, los 
estudiantes aprovechan las características de hipertexto de HyperCase en la Web para crear 
sus propias rutas individuales dentro de la organización. 

Maple Ridge Engineering es resultado directo de las experiencias reales de consultoría 
de los autores de la versión original (Raymond Barnes, Richard Baskerville, Julie E. Kendall y 
Kenneth E. Kendall). Alien Schmidt se integró al proyecto en la versión 2.0. Peter Schmidt 
ñte el programador de HTML y Jason Reed produjo las imágenes para la versión de la Web. 

En cada capítulo hay Experiencias con HyperCase especiales que incluyen tareas (al 
igual que algunas pistas) para ayudar a los estudiantes a resolver los difíciles problemas or¬ 
ganizacionales que enfrentarán en MRE. HyperCase se ha probado totalmente en los salo¬ 
nes de clase y obtuvo un premio en el certamen Decisión Sciences Institute Innovative. 







EPISODIOS DE LOS CASOS DE LA CPU 

Acordes con nuestra creencia de que es importante contar con una di¬ 
versidad de enfoques, nuevamente hemos integrado el caso de la Cen¬ 
tral Pacific University (CPU) en cada uno de los capítulos de esta sexta edición. En las pan¬ 
tallas de ejemplo y los ejercicios de los estudiantes, el caso de la CPU utiliza la popular 
herramienta CASE Visible Analyst, de Visible Sys¬ 
tems, Inc. 

El caso de la CPU lleva a los estudiantes por to¬ 
das las fases del ciclo de vida del desarrollo de siste¬ 
mas, demostrando las capacidades de Visible Analyst. 

Esta herramienta CASE permite a los estudiantes 
resolver problemas por sí mismos, utilizando datos 
que pueden descargar del sitio Web con ejercicios de 
Visible Analyst especialmente diseñados para cada 
capítulo del libro. Además, en el sitio Web se en¬ 
cuentran archivos de Microsoft Access parcialmente 
terminados para que los utilice el estudiante. El caso 
de la CPU ha sido completamente probado en los 
salones por una gran cantidad de estudiantes, duran¬ 
te numerosos periodos. El caso es suficientemente 
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detallado, riguroso y rico para funcionar como un proyecto independiente de análisis y dise¬ 
ño de sistemas con una duración de uno o dos periodos. De manera alternativa, el caso de 
la CPU se puede aprovechar para enseñar el uso de herramientas CASE en conjunto con la 
asignación de un proyecto real, de uno o dos periodos, fuera del salón de clases. 



APOYOS ADICIONALES EN LA WEB 

La sexta edición de Análisisy diseño de sistemas, de Kendall y Kendall, incorpora apoyo adicio¬ 
nal en la Web a las técnicas pedagógicas en el campo de los sistemas de información. Cabe acla¬ 
rar que toda esta información está en idioma inglés. 

8 El sitio Web de este libro (www.pearsoneduca- 
cion.net/kendall) contiene numerosas herra¬ 
mientas de apoyo y aprendizaje, que animan las 
discusiones en clase. 

# HyperCase 2.5, un galardonado juego sobre 
una organización virtual interactiva. Los estu¬ 
diantes podrán entrevistar a miembros de la or¬ 
ganización, analizar problemas, modificar dia¬ 
gramas de flujo de datos y diccionarios de datos, responder a prototipos y diseñar 
nuevas formas de entrada y salida. HyperCase cuenta ahora con una apariencia tri¬ 
dimensional. 

oEjerciciosparaelestudiantebasadosenelcaso l™lT« AA /S>|>>» IVT» H1HIl»[Ml\llllM„ i\ii\i\r.vi»^-i 
continuo de la CPU, con problemas y ejemplos í, '** - i ^ . . . « g - . r ,. - 

parcialmente resueltos en archivos de Visible 

Analyst y Microsoft Access, con el fin de que los c;.:. . íw«ittMxwiMnm í 

J j 1 . • MÑUtfuaMI’.:,' : *1 r—q 

alumnos puedan desarrollar un sistema de ad- «*—■•» i 

ministración basado en la Web. I^ST’ í 

8 Guía de estudio interactiva, con preguntas cierto M _Ü 

o falso y de opción múltiple para cada capítulo. <—■» >- . — as sb 

Los estudiantes reciben una calificación auto- ■■ .... 

iL__ — _;_• • • . : ■ ..;_■ . ■ 'l . -'r- Z _ 

mática y ayuda para contestar cada cuestionario. 

• Manual del profesor (en una sección segura para profesores) con respuestas a pro¬ 
blemas, soluciones a los casos y sugerencias para impartir la materia. 

9 Un paquete completo de diapositivas de PowerPoint que se pueden emplear en 
conferencias y que incluyen todas las figuras técnicas de la sexta edición. 

8 Muestras de esquemas de cursos para cursos de uno o dos semestres o trimestres. 

8 Soluciones a ejercicios para los estudiantes basados en el caso continuo de la CPU, 
con soluciones y ejemplos en archivos de Visible Analyst y Microsoft Access. 

8 La Guía de la Corporación para los Usuarios de HyperCase, una guía del profe¬ 
sor para interpretar el HyperCase y enfoques sugeridos para utilizar en el salón de 
clases. 


i-U * p' viÑ 


MATERIAL DE APOYO EN LA WEB PARA EL PROFESOR (EN INGLES) 

En el sitio Web de este libro se encontrará una mayor cantidad de material de apoyo para 
los profesores que utilicen esta edición. Entre los recursos se cuentan: 

8 Un paquete completo de diapositivas de PowerPoint para utilizarse en conferencias. 

8 Biblioteca de imágenes, una colección de imágenes organizadas por capítulo. 

8 Manual del profesor en Microsoft Word. 

• Archivo de pruebas en Microsoft Word. 

• Windows PH Test Manager, un completo paquete de herramientas para probar y 
evaluar que permite a los profesores crear y distribuir pruebas con suma facilidad. 

8 Soluciones a los ejercicios para el estudiante basados en el caso continuo de la 
CPU, con soluciones y ejemplos en archivos de Visible Analyst y Microsoft Access. 
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Cuando comenzamos a escribir la sexta edición de Análisis y diseño de sistemas observamos 
un mayor énfasis en la calidad de la información y en los sistemas de información, así co¬ 
mo un creciente interés por el uso de la tecnología de la información y nuevos sistemas 
para mejorar la productividad y la calidad de vida de los individuos, al igual que la calidad 
de las sociedades establecidas y las emergentes. Mucha gente de todas partes del mundo se 
especializa en el diseño de sistemas, y aún más gente se ve en la necesidad de utilizar avan¬ 
zados sistemas e información basados en la Web. Los usuarios responden a los sistemas de 
información y participan en el desarrollo de los mismos. Los buenos analistas y diseñadores 
de sistemas aprovechan tanto el arte como la ciencia al dar respuesta a la retroalimentación 
que reciben, con el fin de desarrollar sistemas adecuados para sus usuarios, sus entornos e 
incluso la sociedad. 

El artista que creó la ilustración de nuestra portada, Douglas G. Hamilton, comentó lo 
siguiente acerca de su pintura, Sydney II (que vimos por primera vez en un maravilloso sitio 
Web llamado ArtQuest): "Aunque con frecuencia hay diseños premeditados, colores senci¬ 
llos o límites difíciles, en todo subyace en gran medida el azar. Con frecuencia, las cosas más 
interesantes ocurren de manera casual cuando nos aventuramos a ir más allá de lo estableci¬ 
do, experimentando y combinando con la aleatoriedad de otros". 

Creemos que usted estará de acuerdo en que la creación de una pintura es similar a lo 
que ocurre al crear nuevos sistemas de información. Usted tiene que aprender y aplicar una 
gran cantidad de técnicas, métodos, herramientas y enfoques estructurados. Pero cuando lle¬ 
ga el momento de interpretar lo que acontece en la organización y de desarrollar sistemas 
de información significativos desde la aplicación de reglas hasta el análisis, su capacidad se 
combina con su creatividad para producir un sistema que en cierta forma constituye una 
sorpresa: de múltiples capas y complejo, de acuerdo con las particularidades de la organiza¬ 
ción, y que refleja la individualidad de usted como analista de sistemas. 

Como ocurre con cualquier nueva edición, nuestros estudiantes merecen reconocimien¬ 
to por habernos ayudado a mejorar de manera continua este libro al compartir con nosotros 
sus ideas y comentarios. Apreciamos su disposición para enseñarnos nuevas cosas. Deseamos 
agradecer a Alien Schmidt, coautor, todo el talento, dedicación y humorismo que puso en 
sus colaboraciones. Es una persona sin igual. También damos un profundo reconocimiento a 
Peter Schmidt y Jason Reed por sus contribuciones al HyperCase. Asimismo, agradecemos 
a Richard Baskerville y Raymond Barnes, los otros dos autores originales del HyperCase, por 
su valiosa aportación. 

Deseamos hacer patente nuestro agradecimiento a Bob Horan, nuestro editor, quien 
nos impulsó a hacer de ésta una edición dinámica y sustancial. Kyle Hannon también nos 
ayudó a realizar una revisión a fondo. Sharon Koch merece nuestro agradecimiento por 
haber aplicado sus conocimientos de marketing en nuestro texto. Su percepción, visión y 
capacidad favorecieron que este proyecto cumpliera nuestros objetivos compartidos. 

Maggie Nickles y Stacey Corbin, nuestros editores de producción en ICC, también me¬ 
recen muchos elogios por habernos ayudado en la difícil tarea de establecer prioridades y 
apegarnos a ellas. Gracias a ellos, esta edición fluyó sin problemas. Por último, hubo mucha 
gente que no conocimos personalmente, pero con la que trabajamos en equipos virtuales en 
Prentice Hall, como Suzanne Grappi, e incluso otros miembros de ICC y de otras áreas, que 
nos ayudaron a administrar el proyecto, diseñar el libro, dibujar las ilustraciones, diagramar 
las páginas y conseguir los permisos correspondientes. Damos las gracias a todos ellos. 




Muchos revisores, compañeros y amigos nos animaron durante el proceso de redacción 
de este libro. Les damos las gracias por sus comentarios a nuestro trabajo. Entre ellos están: 
Ayman Abu Hamdieh; Jim y Jan Buffington; Chaomei Chen; Charles J. Coleman; Gordon 
Davis; Dorothy Dologite; Jim Evans; Bruce Fanning; Paul Gray; Nancy V. Gulick; Andy 
y Pam Hamingson; Chung Kwong Han; Carolyn Harris; Gail S. Huck; Ken y Nancy Kopecky; 
Art y Joan Kraft; Lee y Judie Krajewski; Muhammadou y Jainaba Kah; Kathy Kahre-Samuels; 
Carol Latta; Ken y Jane Laudon; Cliffbrd D. Layton; Bob Mankoff; Sylnovie Merchant; 
Merrideth Miller; Robert Moclder; Nancy Omaha Boy; Raymond E. Podhorn; Joel y Bobbie 
Porter; Markita Price; Ron Rice; Bill Rogers; Caryn Schmidt; Marc y Jill Schniederjans; Keng 
Siau; Jeffery L. Squibb; Ene y Tisha Stahl; Merrill Warkentin; Shaker y Patricia Zahra, y to¬ 
dos nuestros amigos y compañeros en la Association for Information Systems, el Decisión 
Sciences Institute, el IFIP Working Group 8.2, y todos los que participan en el KPMG Ph.D. 
Project. 

Gracias de todo corazón a Julia A. Kendall y a la memoria de Edward J. Kendall. Su fir¬ 
me convicción de que el amor, las metas y el trabajo constante constituyen una combina¬ 
ción inigualable continúa impulsando nuestros esfuerzos cotidianos. 
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OBJETIVOS DE APRENDIZAJE 


Una vez que haya dominado el material de este capitulo, podrá: 

1. Recordar los tipos básicos de sistemas de computo con los que debe trabajar un analista de sistemas. 

2. Entender la manera en que las nuevas tecnologías influyen en la dinámica de un sistema. 

3. Reconocer los diversos roles de un analista de sistemas. 

4. Conocer los pasos del SDLC y saber como aplicarlos a un sistema real. 

5. Comprender la función de las herramientas CASE y cómo ayudan a un analista de sistemas. 

' 6. Explorar otras metodologías como el diseño de sistemas^ orientados a objetos y la elaboración 
■ ' de prototipos;' l •' 


.Desde tucé' mucho tiempo, las oruan i/ai jones. -h;in reconocido I;:: importanciá;do adniinis-;. 
írM": recursos chivo corno ¡a mano do'obra Vías; materias prima:-: íjí la :u:lu;i)iil¡úL la irtforma- 
cióp.so ha .uanado el legítimo derecho de ser considerada como un recurso clavo. Los; riu:ár : 
liados tío lí tom'.'t do decisiones por tin han comprendido que .la información no es tari sólo 
un qJ'J "ndiKtu ilorivado do fa <?,ondiK;ción vio los penocios, sino un irhpíiisor iló.lds miamos y 
que neeili¿ constituir un factor cnuj/l en ol rxiro o jraca A o ilo una oinruv-ja. 

IV.IM ma\i:n7LLr !a utilidad do ia iníonn.'ieión.. LIP;I ompjosi (K-fPf. 1 adminisfarla do riiañq- 
i'h oíii'irnlii, r.(|;üo i o ’¡meo ion ios desdas rocursiv-s L .o* adminislradorof'dobon coiunrondor: 
t;í;o lg j. cpsíót; ji'oncí una estrecha relación con la producción, dislrihiihion, souiiritlüd, ¡ ililu- 
n ; namienÜ)vyiocul.ioiMfión dr r lothi la io'urnuK'íon, A "posar A tjnt-, la mi’ornr.ldón oátá en 
indas p .irltts, no ,í_s j }>r.ii;ij:a. y no.M 1 Jobo .asumir qué se poilrá usar osiralójiicamenio para au- : ' 
nirP.lar la óompotitividan ilo una empivsa. . 

La umpl:':-. disponibilidad de computadoras, bn. red, j unto con OI acceso a Internet y la 
World \\5do Wéb, han .¡iropiciado Lina e\nJostón Cic la intormatión en la .sociedad en general 
AryiLios Menucios on particular. I .a administración de-h: inhirmaoióhjicrior’.'.da por tomnuiado- :. 
ra difiero en á.sptuoa imporlanle.i del niancjü de los datos producidos por medios manuales'. 
Por lo. general hay" una mayor cantidad, de información de computadora por manejar. Los 
costos de. organizaría y darle manten i miento se pueden incrementar a niveles-al armantes,' 
y con frecuencia, los usuarios Iq consideran más precisa queda información obtenida por 
otros medios. En este: capituló se examinan, los aspectos básicos, dé los diferentes tipos de 
sistemas de información, los diversos roles cié los .analistas de sistemas, las fases del ciclo 
de vida del desarrollo de sistemas {SDLC, Systems Development Lije Cyrlt‘1 y se presentan, 
lásí hérramiéritás de Ingeniería dé;Software Asistida por Computadora (CÁSE, Computer- 
Aídécl :Software Erígíneerlng}..--; ' :í.■ ó. v ' 
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TIPOS DE SISTEMAS 


Los sistemas de información se desarrollan con diversos propósitos, según las necesidades de la 
empresa. Los sistemas de procesamiento de transacciones (TPS, Transaction Processing Systems) 
funcionan al nivel operativo de una organización, los sistemas de automatización de la oficina 
(OAS, OfficeAutomañon Systems) y los sistemas de trabajo del conocimiento (KWS, Knowledge 
Work Systems) apoyan el trabajo al nivel del conocimiento. Los sistemas de información geren- 
cial (MIS, Management Information Systems) y los sistemas de apoyo a la toma de decisiones 
(DSS, Decisión Support Systems) se encuentran entre los sistemas de alto nivel. Los sistemas ex¬ 
pertos aplican el conocimiento de los encargados de la toma de decisiones para solucionar pro¬ 
blemas estructurados específicos. Los sistemas de apoyo a ejecutivos (ESS, Executive Support 
Systems) se encuentran en el nivel estratégico de la administración. Los sistemas de apoyo a la 
toma de decisiones en grupo (GDSS, Group Decisión Support Systems) y los sistemas de tra¬ 
bajo corporativo apoyados por computadora (CSCWS, Computer-Supported Collaborative 
Work Systems), descritos de manera más general, auxilian la toma de decisiones semiestruc- 
turadas o no estructuradas a nivel de grupo. 

En la figura 1.1 se muestra la diversidad de sistemas de información que podrían desa-' 
rrollar los analistas. Observe que en la figura estos sistemas se representan de abajo hacia arri¬ 
ba, indicando que los TPS apoyan el nivel operativo, o más bajo, de la organización, mientras 
que los ESS, GDSS y CSCWS soportan el nivel estratégico, o más alto, apoyando la toma de 
decisiones semiestructuradas o las no estructuradas. En este libro se emplean de manera in¬ 
distinta los términos sistemas de información gerencia!, sistemas de información (IS, Informa¬ 
tion Systems), sistemas de información computarizados y sistemas de información de negocios 
computerizados, para denotar sistemas de información computarizados que apoyan el rango 
de actividades de negocios más amplio mediante la información que producen. 

SISTEMAS DE PROCESAMIENTO DE TRANSACCIONES 

Los sistemas de procesamiento de transacciones (TPS, Transaction Processing Systems) son 
sistemas de información computarizada creados para procesar grandes cantidades de datos 
relacionadas con transacciones rutinarias de negocios, como las nóminas y los inventarios. 
Un TPS elimina el fastidio que representa la realización de transacciones operativas necesa¬ 
rias y reduce el tiempo que una vez fue requerido para llevarlas a cabo de manera manual, 
aunque los usuarios aún tienen que capturar datos en los sistemas computarizados. 

Los sistemas de procesamiento de transacciones expanden los límites de la organización 
dado que le permiten interactuar con entornos externos. Es importante para las operaciones 
cotidianas de un negocio, que estos sistemas funcionen sin ningún tipo de interrupción, puesto 
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que los administradores recurren a los datos producidos por los TPS con el propósito de obte¬ 
ner información actualizada sobre el funcionamiento de sus empresas. 

SISTEMAS DE AUTOMATIZACIÓN DE LA OFICINA Y SISTEMAS DE TRABAJO DEL CONOCIMIENTO 

Existen dos clases de sistemas en el nivel del conocimiento de una organización. Los siste¬ 
mas de automatización de la oficina [OAS, Office Automation Systems] apoyan a los trabaja¬ 
dores de datos, quienes por lo general no generan conocimientos nuevos, sino más bien ana¬ 
lizan la información con el propósito de transformar los datos o manipularlos de alguna 
manera antes de compartirlos o, en su caso, distribuirlos formalmente con el resto de la or¬ 
ganización y en ocasiones más allá de ésta. Entre los componentes más comunes de un OAS 
están el procesamiento de texto, las hojas de cálculo, la autoedición, la calendarización elec¬ 
trónica y las comunicaciones mediante correo de voz, correo electrónico y videoconferencia. 

Los sistemas de trabajo del conocimiento (KWS, Knowledge Work Systems] sirven de 
apoyo a los trabajadores profesionales, como los científicos, ingenieros y médicos, en sus es¬ 
fuerzos de creación de nuevo conocimiento y dan a éstos la posibilidad de compartirlo con 
sus organizaciones o con la sociedad. 

SISTEMAS DE INFORMACIÓN GERENCIAL 

Los sistemas de información gerencial (MIS, Management Information Systems] no reempla¬ 
zan a los sistemas de procesamiento de transacciones, más bien, incluyen el procesamiento 
de transacciones. Los MIS son sistemas de información computarizados cuyo propósito es 
contribuir a la correcta interacción entre los usuarios y las computadoras. Debido a que re¬ 
quieren que los usuarios, el software [los programas de cómputo] y el hardware (las compu¬ 
tadoras, impresoras, etc.), funcionen de manera coordinada, los sistemas de información ge¬ 
rencial dan apoyo a un espectro de tareas organizacionales mucho más amplio que los 
sistemas de procesamiento de transacciones, como el análisis y la toma de decisiones. 

Para acceder a la información, los usuarios de un sistema de información gerencial com¬ 
parten una base de datos común. Ésta almacena datos y modelos que ayudan al usuario a in¬ 
terpretar y aplicar los datos. Los sistemas de información gerencial producen información 
que se emplea en la toma de decisiones. Un sistema de información gerencial también pue¬ 
de contribuir a unificar algunas de las funciones de información computarizadas de una em¬ 
presa, a pesar de que no existe como una estructura individual en ninguna parte de ésta. 

SISTEMAS DE APOYO A LA TOMA DE DECISIONES 

Los sistemas de apoyo a la toma de decisiones (DSS, Decisión Support Systems] constituyen 
una clase de alto nivel de sistemas de información computarizada. Los DSS coinciden con 
los sistemas de información gerencial en que ambos dependen de una base de datos para 
abastecerse de datos. Sin embargo, difieren en que el DSS pone énfasis en el apoyo a la to¬ 
ma de decisiones en todas sus fases, aunque la decisión definitiva es responsabilidad exclu¬ 
siva del encargado de tomarla. Los sistemas de apoyo a la toma de decisiones se ajustan más 
al gusto de la persona o grupo que los utiliza que a los sistemas de información gerencial 
tradicionales. En ocasiones se hace referencia a ellos como sistemas que se enfocan en la in¬ 
teligencia de negocios. 


SISTEMAS EXPERTOS E INTELIGENCIA ARTIFICIAL 


La inteligencia artificial (AI, ArtificialIntelligence] se puede considerar como el campo gene¬ 
ral para los sistemas expertos. La motivación principal de la AI ha sido desarrollar máquinas 
que tengan un comportamiento inteligente. Dos de las líneas de investigación de la AI son 
la comprensión del lenguaje natural y el análisis de la capacidad para razonar un problema 
hasta su conclusión lógica. Los sistemas expertos utilizan las técnicas de razonamiento de la 
AI para solucionar los problemas que les plantean los usuarios de negocios (y de otras 
áreas]. 

Los sistemas expertos conforman una clase muy especial de sistema de información 
que se ha puesto a disposición de usuarios de negocios gracias a la amplia disponibilidad de 
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hardware y software como computadoras personales (PCs) y generadores de sistemas ex¬ 
pertos. Un sistema experto [también conocido como sistema basado en el conocimiento) 
captura y utiliza el conocimiento de un experto para solucionar un problema específico en 
una organización. Observe que a diferencia de un DSS, que cede al responsable la toma de 
la decisión definitiva, un sistema experto selecciona la mejor solución para un problema o 
una clase específica de problemas. 

Los componentes básicos de un sistema experto son la base de conocimientos, un 
motor de inferencia que conecta al usuario con el sistema mediante el procesamiento de 
consultas realizadas con lenguajes como SQL [Structured Query Language, lenguaje de con¬ 
sultas estructurado) y la interfaz de usuario. Profesionales conocidos como ingenieros de 
conocimiento capturan la pericia de los expertos, construyen un sistema de cómputo que con¬ 
tiene este conocimiento experto y lo implementan. Es muy factible que la construcción e 
implementación de sistemas expertos se constituya en el trabajo futuro de muchos analistas 
de sistemas. 

SISTEMAS DE APOYO A LA TOMA DE DECISIONES EN GRUPO Y SISTEMAS 
DE TRABAJO COLABORATIVO APOYADOS POR COMPUTADORA 

Cuando los grupos requieren trabajar en conjunto para tomar decisiones semiestructuradas 
o no estructuradas, un sistema de apoyo a la toma de decisiones en grupo (GDSS, Group 
Decisión Support System) podría ser la solución. Este tipo de sistemas, que se utilizan en 
salones especiales equipados con diversas configuraciones, faculta a los miembros del grupo 
a interactuar con apoyo electrónico —casi siempre software especializado— y la asistencia 
de un facilitador especial. Los sistemas de apoyo a la toma de decisiones en grupo tienen el 
propósito de unir a un grupo en la búsqueda de la solución a un problema con la ayuda de 
diversas herramientas como los sondeos, los cuestionarios, la lluvia de ideas y la creación 
de escenarios. El software GDSS puede diseñarse con el fin de minimizar las conductas ne¬ 
gativas de grupo comunes, como la falta de participación originada por el miedo a las repre¬ 
salias si se expresa un punto de vista impopular o contrario, el control por parte de miem¬ 
bros elocuentes del grupo y la toma de decisiones conformista. En ocasiones se hace 
referencia a los GDSS con el término más general sistemas de trabajo colaborativo apoyados 
por computadora (CSCWS, Computer-Supported Collaborative Work Systems], que pueden 
contener el respaldo de un tipo de software denominado groupware para la colaboración en 
equipo a través de computadoras conectadas en red. 

SISTEMAS DE APOYO A EJECUTIVOS 

Cuando los ejecutivos recurren a la computadora, por lo general lo hacen en busca de mé¬ 
todos que los auxilien en la toma de decisiones de nivel estratégico. Los sistemas de apoyo a 
ejecutivos (ESS, Executive Support Systems) ayudan a estos últimos a organizar sus actividades 
relacionadas con el entorno externo mediante herramientas gráficas y de comunicaciones, 
que por lo general se encuentran en salas de juntas o en oficinas corporativas personales. A 
pesar de que los ESS dependen de la información producida por los TPS y los MIS, ayudan 
a los usuarios a resolver problemas de toma de decisiones no estructuradas, que no tienen 
una aplicación específica, mediante la creación de un entorno que contribuye a pensar 
en problemas estratégicos de una manera bien informada. Los ESS amplían y apoyan las ca¬ 
pacidades de los ejecutivos al darles la posibilidad de comprender sus entornos. 


INTEGRACIÓN DE LAS TECNOLOGÍAS DE SISTEMAS 

Como se aprecia en la figura 1.2, a medida que se adopten y difundan las nuevas tecnolo¬ 
gías, parte del trabajo de los analistas de sistemas se dedicará a la integración de los sistemas 
tradicionales con los nuevos. En esta sección se describen algunas de las nuevas tecnologías 
de información que los analistas de sistemas utilizarán para empresas que buscan integrar 
sus aplicaciones de comercio electrónico con sus negocios tradicionales, o bien, iniciar nego¬ 
cios electrónicos completamente nuevos. 
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APLICACIONES DE COMERCIO ELECTRÓNICO Y SISTEMAS WEB 

Muchos de los sistemas que se describen en este libro pueden dotarse de una mayor funcio¬ 
nalidad si se migran a la World Wide Web o si desde su concepción se implementan como 
tecnologías basadas en la Web. En una encuesta reciente la mitad de todas las empresas pe¬ 
queñas y medianas respondieron que Internet fue su estrategia preferida para buscar el cre¬ 
cimiento de sus negocios. Esta respuesta duplicó a la de aquellos que manifestaron su incli¬ 
nación por realizar alianzas estratégicas como medio para crecer. Hay muchos beneficios 
derivados de la implementación de una aplicación en la Web: 

1. Una creciente difusión de la disponibilidad de un servicio, producto, industria, persona 
o grupo. 

2. La posibilidad de que los usuarios accedan las 24 horas. 

3. La estandarización del diseño de la interfaz. 

4. La creación de un sistema que se puede extender a nivel mundial y llegar a gente en lu¬ 
gares remotos sin preocuparse por la zona horaria en que se encuentren. 

SISTEMAS DE PLANEACIÓN DE RECURSOS EMPRESARIALES 

Muchas organizaciones consideran los beneficios potenciales que se derivan de la integra¬ 
ción de los diversos sistemas de información que existen en los diferentes niveles adminis¬ 
trativos, con funciones dispares. Esta integración es precisamente el propósito de los sistemas 
de planeación de recursos empresariales (ERP, Enterprise Resource Planning). El estableci¬ 
miento de los sistemas ERP implica un enorme compromiso y cambio por parte de la orga¬ 
nización. Es común que los analistas de sistemas desempeñen el papel de asesores en los 
proyectos de ERP que utilizan software patentado. Entre el software más conocido de ERP 
se encuentran SAP, PeopleSoft y paquetes de Oracle y J.D. Edwards. Algunos de estos paque¬ 
tes están diseñados para migrar a las empresas a la Web. Por lo general, los analistas y algunos 
usuarios requieren capacitación, apoyo técnico y mantenimiento por parte del fabricante 
para diseñar, instalar, dar mantenimiento, actualizar y utilizar de manera apropiada un pa¬ 
quete de ERP en particular. 

SISTEMAS PARA DISPOSITIVOS INALÁMBRICOS Y PORTÁTILES 

Los analistas tienen la exigencia de diseñar una gran cantidad de nuevos sistemas y aplica¬ 
ciones, muchos de ellos para dispositivos inalámbricos y computadoras portátiles como la 














popular serie de computadoras Palm y otros asistentes personales digitales (PDAs, Personal 
Digital Assistants], Además, los analistas podrían llegar a diseñar redes de comunicaciones 
estándar o inalámbricas que integren voz, vídeo y correo electrónico en intranets para una 
organización o extrañéis para la industria. El comercio electrónico inalámbrico se conoce 
como comercio móvil o m-commerce. 

Las redes inalámbricas de área local [WLANs, Wireless Local Area Networks), las redes 
de fidelidad inalámbrica, conocidas como WI-FI, y las redes inalámbricas personales que 
agrupan a muchos tipos de dispositivos dentro del estándar conocido como Bluetooth, 
constituyen sistemas cuyo diseño podrían solicitarle a usted en su función de analista. (Para 
ahondar en las redes inalámbricas, véase el capítulo 17.) 

En un contexto más avanzado, al analista podría solicitársele el diseño de agentes inte¬ 
ligentes, software que puede ayudar a los usuarios a ejecutar tareas mediante el aprendizaje 
de las preferencias del usuario a través del tiempo y, a continuación, realizando alguna ac¬ 
ción sobre éstas. Por ejemplo, en la tecnología de recepción automática, un agente inteligen¬ 
te podría buscar temas de interés para el usuario en la Web, sin necesidad de que éste lo so¬ 
licite, después de observar durante algún tiempo los patrones de comportamiento del 
usuario en relación con la información. 

Un ejemplo de este tipo de software es el que desarrolla Microsoft con base en la esta¬ 
dística bayesiana (donde se utilizan estadísticas para inferir probabilidades) y la teoría de la 
toma de decisiones, en conjunto con el monitoreo del comportamiento de un usuario que 
maneja información entrante (como un mensaje de su casa, una llamada telefónica de un 
cliente, una llamada de celular o el análisis actualizado de su cartera de acciones). El resulta¬ 
do es software de manejo de notificaciones que da un valor monetario a cada pieza de infor¬ 
mación proveniente de diversas fuentes y también determina la mejor manera de desplegarla. 
Por ejemplo, con base en la teoría de la toma de decisiones, la probabilidad, la estadística y 
el propio comportamiento del usuario, a una llamada telefónica proveniente de la casa del 
usuario se le podría dar el valor de un peso y se desplegaría en la pantalla de la computado¬ 
ra, en tanto que a una llamada cuyo propósito es la venta de algún producto o servicio se le 
podría asignar el valor de 20 centavos (es decir, un valor inferior) y podría desplegarse como 
nota en un radiolocalizador. 

SOFTWARE DE CÓDIGO ABIERTO 

El software de código abierto es una alternativa al desarrollo de software tradicional cuyo có¬ 
digo patentado se oculta a los usuarios. Representa un modelo de desarrollo y filosofía de dis¬ 
tribución de software gratuito y publicación de su código fuente. Bajo este esquema, el códi¬ 
go (las instrucciones para la computadora) se puede estudiar y compartir, y muchos usuarios 
y programadores tienen la posibilidad de modificarlo. Las convenciones que rigen a esta co¬ 
munidad incluyen que todas las modificaciones que se hagan a un programa deben compar¬ 
tirse con todos aquellos que participan en el proyecto. Entre los ejemplos se encuentran el 
sistema operativo Linux y el software Apache empleado en servidores que alojan sitios Web. 

Si el software es de distribución gratuita, ¿cómo ganan dinero las compañías? Para ello, 
tienen que proporcionar un servicio, personalizar programas para los usuarios y darles segui¬ 
miento con un soporte continuo. En un mundo de software de código abierto, el desarrollo 
de sistemas continuaría su evolución hacia una industria de servicios. Se apartaría del mode¬ 
lo de manufactura en el que los productos se licencian y empacan en cajas vistosas y se en¬ 
vían hasta nuestras puertas, al igual que cualquier otro producto manufacturado. 

El desarrollo de código abierto es útil para los dispositivos portátiles y el equipo de co¬ 
municaciones. Su uso podría estimular el progreso en la creación de estándares para que los 
dispositivos se comunicaran con más facilidad. El uso generalizado del software de código 
abierto podría solucionar problemas que pudiera causar la escasez de programadores y algunos 
problemas complejos podrían resolverse mediante la colaboración de muchos especialistas. 


LA NEC ES i’ DA D ÍE LA N K í ’ S fs y D | SÉ M ’ D E S I ST É M AS 


El análisis y diseño de sistemas, tal como lo realizan los analistas de sistemas, tiene el propó¬ 
sito de analizar sistemáticamente la entrada o el flujo de datos, procesar o transformar da- 
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Y ésta es la razón por la cual necesitamos una computadora. 

tos, el almacenamiento de datos y la salida de información en el contexto de una empresa 
en particular. Más aún, el análisis de sistemas se emplea para analizar, diseñar e implementar 
mejoras en el funcionamiento de las empresas, a través de sistemas de información compu- 
tarizados. 

La instalación de un sistema sin una planeación adecuada conduce a una gran decepción 
y con frecuencia provoca que el sistema deje de utilizarse. El análisis y diseño de sistemas da 
forma al análisis y diseño de sistemas de información, un esfuerzo muy valioso que de otra 
manera podría haberse realizado de una manera fortuita. Se le puede considerar como una 
serie de procesos sistemáticamente emprendidos con el propósito de mejorar un negocio 
con ayuda de sistemas de información computarizados. Gran parte del análisis y diseño de 
sistemas implica trabajar con usuarios actuales y ocasionales de los sistemas de información. 

Es importante que los usuarios intervengan de alguna manera durante el proyecto para 
completar con éxito los sistemas de información computarizados. Los analistas de sistemas, 
cuyos roles en la organización se describen a continuación, constituyen el otro componente 
esencial en el desarrollo de sistemas de información útiles. 


ROLES DEL ANALISTA DE SISTEMAS 

El analista de sistemas evalúa de manera sistemática el funcionamiento de un negocio me¬ 
diante el examen de la entrada y el procesamiento de datos y su consiguiente producción de 
información, con el propósito de mejorar los procesos de una organización. Muchas mejoras 
incluyen un mayor apoyo a las funciones de negocios a través del uso de sistemas de informa¬ 
ción computarizados. Esta definición pone énfasis en un enfoque sistemático y metódico 
para analizar—y en consecuencia mejorar— lo que sucede en el contexto específico creado 
por un negocio. 

Nuestra definición de analista de sistemas es amplia. El analista debe tener la capacidad 
de trabajar con todo tipo de gente y contar con suficiente experiencia en computadoras. El 
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profesional con el hardware y software de cómputo y al uso que se le da en el negocio. Con 
frecuencia, este trabajo no implica un proyecto completo de sistemas, sino más bien la rea¬ 
lización de pequeñas modificaciones o la toma de decisiones que se circunscriben a un solo 
departamento. 

Como experto de soporte técnico, usted no está a cargo del proyecto; tan sólo actúa co¬ 
mo recurso para aquellos que sí lo están. Si usted es un analista de sistemas contratado por 
una empresa de manufactura o servicios, gran parte de sus actividades podrían ajustarse a 
este rol. 

EL ROL DE AGENTE DE CAMBIO DEL ANALISTA DE SISTEMAS 

El rol más completo y de mayor responsabilidad que asume el analista de sistemas es el de 
agente de cambio, ya sea interno o externo para la empresa. Como analista, usted es un agen¬ 
te de cambio si desempeña cualquiera de las actividades relacionadas con el ciclo de vida 
del desarrollo de sistemas (que se explicará en la siguiente sección) y está presente en la em¬ 
presa durante un largo periodo (de dos semanas a más de un año}. Un agente de cambio se 
puede definir como alguien que sirve de catalizador para el cambio, desarrolla un plan para 
el cambio y coopera con los demás para facilitar el cambio. 

Su presencia en el negocio inicia el cambio. Como analista de datos, usted debe estar 
consciente de este hecho y utilizarlo como punto de partida para su análisis. De ahí que ten¬ 
ga que interactuar con los usuarios y la administración (si no son uno solo y el mismo) des¬ 
de el principio de su proyecto. Sin su colaboración usted no podría entender lo que ocurre 
en una organización y el cambio real nunca se daría. 

Si el cambio (es decir, las mejoras al negocio que se pueden concretar mediante los sis¬ 
temas de información) parece factible después de efectuar el análisis, el siguiente paso es 
desarrollar un plan para el cambio de manera conjunta con quienes tienen la facultad de au¬ 
torizarlo. Una vez que se haya alcanzado el consenso acerca de los cambios por realizar, us¬ 
ted tendrá que interactuar constantemente con quienes vayan a cambiar. 

En su calidad de analista de sistemas desempeñando la función de agente de cambio, 
debe promover un cambio que involucre el uso de los sistemas de información. También es 
parte de su tarea enseñar a los usuarios el proceso del cambio, ya que las modificaciones a 
un sistema de información no sólo afectan a éste sino que provocan cambios en el resto de 
la organización. 

CUALIDADES DEL ANALISTA DE SISTEMAS 

De las descripciones anteriores sobre los roles que desempeña el analista de sistemas, se de¬ 
duce fácilmente que el analista exitoso debe contar con una amplia gama de cualidades. 
Hay una gran diversidad de personas trabajando como analistas de sistemas, por lo que 
cualquier descripción que intente ser general está destinada a quedarse corta en algún senti¬ 
do. No obstante, la mayoría de los analistas de sistemas tienen algunas cualidades comunes. 

En primer lugar, el analista es un solucionador de problemas. Es una persona que abor¬ 
da como un reto el análisis de problemas y que disfruta al diseñar soluciones factibles. 
Cuando es necesario, el analista debe contar con la capacidad de afrontar sistemáticamente 
cualquier situación mediante la correcta aplicación de herramientas, técnicas y su experiencia. 
El analista también debe ser un comunicador con capacidad para relacionarse con los demás 
durante extensos periodos. Necesita suficiente experiencia en computación para programar, 
entender las capacidades de las computadoras, recabar los requisitos de información de los 
usuarios y comunicarlos a los programadores. Asimismo, debe tener una ética personal y 
profesional firme que le ayude a moldear las relaciones con sus clientes. 

El analista de sistemas debe ser una persona autodisciplinada y automotivada, con la 
capacidad de administrar y coordinar los innumerables recursos de un proyecto, incluyendo 
a otras personas. La profesión de analista de sistemas es muy exigente; pero es una profesión 
en constante evolución que siempre trae nuevos retos. 
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EL CICLO DE VIDA DEL DESARROLLO DE SISTEMAS 


A lo largo de este capítulo, nos hemos referido al enfoque sistemático que el analista toma 
en relación con el análisis y diseño de sistemas de información. Gran parte de este enfoque 
se incluye en el ciclo de vida del desarrollo de sistemas (SDLC, Systems Development Life 
Cycle). El SDLC es un enfoque por fases para el análisis y el diseño cuya premisa principal 
consiste en que los sistemas se desarrollan mejor utilizando un ciclo específico de activida¬ 
des del analista y el usuario. 

Los analistas no se ponen de acuerdo en la cantidad de fases que incluye el ciclo de vida 
del desarrollo de sistemas, pero en general alaban su enfoque organizado. Aquí hemos divi¬ 
dido el ciclo en siete fases, como se aprecia en la figura 1.3. A pesar de que cada fase se ex¬ 
plica por separado, nunca se realiza como un paso aislado. Más bien, es posible que varias 
actividades ocurran de manera simultánea, y algunas de ellas podrían repetirse. Es más prác¬ 
tico considerar que el SDLC se realiza por fases (con actividades en pleno apogeo que se 
traslapan con otras hasta terminarse por completo) y no en pasos aislados. 

IDENTIFICACIÓN DE PROBLEMAS, OPORTUNIDADES Y OBJETIVOS 

En esta primera fase del ciclo de vida del desarrollo de sistemas, el analista se ocupa de iden¬ 
tificar problemas, oportunidades y objetivos. Esta etapa es crítica para el éxito del resto del 
proyecto, pues a nadie le agrada desperdiciar tiempo trabajando en un problema que no era 
el que se debía resolver. 

La primera fase requiere que el analista observe objetivamente lo que sucede en un ne¬ 
gocio. A continuación, en conjunto con otros miembros de la organización, el analista deter¬ 
mina con precisión cuáles son los problemas. Con frecuencia los problemas son detectados 
por alguien más, y ésta es la razón de la llamada inicial al analista. Las oportunidades son si¬ 
tuaciones que el analista considera susceptibles de mejorar utilizando sistemas de informa¬ 
ción computarizados. El aprovechamiento de las oportunidades podría permitir a la empresa 
obtener una ventaja competitiva o establecer un estándar para la industria. 

La identificación de objetivos también es una parte importante de la primera fase. En 
primer lugar, el analista debe averiguar lo que la empresa trata de conseguir. A continua¬ 
ción, podrá determinar si algunas funciones de las aplicaciones de los sistemas de información 
pueden contribuir a que el negocio alcance sus objetivos aplicándolas a problemas u opor¬ 
tunidades específicos. 

Los usuarios, los analistas y los administradores de sistemas que coordinan el proyecto 
son los involucrados en la primera fase. Las actividades de esta fase consisten en entrevistar 
a los encargados de coordinar a los usuarios, sintetizar el conocimiento obtenido, estimar el 
alcance del proyecto y documentar los resultados. El resultado de esta fase es un informe de 
viabilidad que incluye una definición del problema y un resumen de los objetivos. A conti¬ 
nuación, la administración debe decidir si se sigue adelante con el proyecto propuesto. Si el 
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grupo de usuarios no cuenta con fondos suficientes, si desea atacar problemas distintos, o si 
la solución a estos problemas no amerita un sistema de cómputo, se podría sugerir una so¬ 
lución diferente y el proyecto de sistemas se cancelaría. 

DETERMINACIÓN DE LOS REQUERIMIENTOS DE INFORMACIÓN 

La siguiente fase que enfrenta el analista es la determinación de los requerimientos de in¬ 
formación de los usuarios. Entre las herramientas que se utilizan para determinar los re¬ 
querimientos de información de un negocio se encuentran métodos interactivos como las 
entrevistas, los muéstreos, la investigación de datos impresos y la aplicación de cuestiona¬ 
rios; métodos que no interfieren con el usuario como la observación del comportamiento de 
los encargados de tomar las decisiones y sus entornos de oficina, al igual que métodos de am¬ 
plio alcance como la elaboración de prototipos. 

El desarrollo rápido de aplicaciones (RAD, RapidApplication Developmeni) es un enfoque 
orientado a objetos para el desarrollo de sistemas que incluye un método de desarrollo 
(que abarca la generación de requerimientos de información) y herramientas de software. 
En este libro se aborda en el capítulo 6, en conjunto con la elaboración de prototipos, por¬ 
que su enfoque filosófico es similar, aunque su método para crear un diseño con rapidez y 
obtener una pronta retroalimentación por parte de los usuarios es un poco diferente. (En el 
capítulo 18 se abunda en los enfoques orientados a objetos.) 

En la fase de determinación de los requerimientos de información del SDLC, el analis¬ 
ta se esfuerza por comprender la información que necesitan los usuarios para llevar a cabo 
sus actividades. Como puede ver, varios de los métodos para determinar los requerimientos 
de información implican interactuar directamente con los usuarios. Esta fase es útil para 
que el analista confirme la idea que tiene de la organización y sus objetivos. En ocasiones 
sólo realizan las dos primeras fases del ciclo de vida del desarrollo de sistemas. Esta clase de 
estudio podría tener un propósito distinto y por lo general la lleva a la práctica un especia¬ 
lista conocido como analista de información (IA, Information Analysi). 

Los implicados en esta fase son el analista y los usuarios, por lo general trabajadores y 
gerentes del área de operaciones. El analista de sistemas necesita conocer los detalles de las 
funciones del sistema actual: el quién (la gente involucrada), el qué (la actividad del nego¬ 
cio), el dónde (el entorno donde se desarrollan las actividades), el cuándo (el momento 
oportuno) y el cómo (la manera en que se realizan los procedimientos actuales) del negocio 
que se estudia. A continuación el analista debe preguntar la razón por la cual se utiliza el 
sistema actual. Podría haber buenas razones para realizar los negocios con los métodos ac¬ 
tuales, y es importante tomarlas en cuenta al diseñar un nuevo sistema. 

Sin embargo, si la razón de ser de las operaciones actuales es que "siempre se han hecho 
de esta manera", quizá será necesario que el analista mejore los procedimientos. La reinge¬ 
niería de procesos de negocios podría ser útil para conceptualizar el negocio de una manera 
creativa. Al término de esta fase, el analista debe conocer el funcionamiento del negocio y 
poseer información muy completa acerca de la gente, los objetivos, los datos y los procedi¬ 
mientos implicados. 


ANÁLISIS DE LAS NECESIDADES DEL SISTEMA 

La siguiente fase que debe enfrentar el analista tiene que ver con el análisis de las necesida¬ 
des del sistema. De nueva cuenta, herramientas y técnicas especiales auxilian al analista en 
la determinación de los requerimientos. Una de estas herramientas es el uso de diagramas 
de flujo de datos para graficar las entradas, los procesos y las salidas de las funciones del ne¬ 
gocio en una forma gráfica estructurada. A partir de los diagramas de flujo de datos se desa¬ 
rrolla un diccionario de datos que enlista todos los datos utilizados en el sistema, así como 
sus respectivas especificaciones. 

Durante esta fase el analista de sistemas analiza también las decisiones estructuradas 
que se hayan tomado. Las decisiones estructuradas son aquellas en las cuales se pueden de¬ 
terminar las condiciones, las alternativas de condición, las acciones y las reglas de acción. 
Existen tres métodos principales para el análisis de decisiones estructuradas: español estruc¬ 
turado, tablas y árboles de decisión. 
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En este punto del ciclo de vida del desarrollo de sistemas, el analista prepara una pro¬ 
puesta de sistemas que sintetiza sus hallazgos, proporciona un análisis de costo/beneficio de 
las alternativas y ofrece, en su caso, recomendaciones sobre lo que se debe hacer. Si la admi¬ 
nistración de la empresa considera factible alguna de las recomendaciones, el analista sigue 
adelante. Cada problema de sistemas es único, y nunca existe sólo una solución correcta. La 
manera de formular una recomendación o solución depende de las cualidades y la prepara¬ 
ción profesional de cada analista. 


DISEÑO DEL SISTEMA RECOMENDADO 

En la fase de diseño del ciclo de vida del desarrollo de sistemas, el analista utiliza la informa¬ 
ción recopilada en las primeras fases para realizar el diseño lógico del sistema de información. 
El analista diseña procedimientos precisos para la captura de datos que aseguran que ios datos 
que ingresen al sistema de información sean correctos. Además, el analista facilita la entra¬ 
da eficiente de datos al sistema de información mediante técnicas adecuadas de diseño de 
formularios y pantallas. 

La concepción de la interfaz de usuario forma parte del diseño lógico del sistema de 
información. La interfaz conecta al usuario con el sistema y por tanto es sumamente impor¬ 
tante. Entre los ejemplos de interfaces de usuario se encuentran el teclado (para teclear 
preguntas y respuestas), los menús en pantalla (para obtener los comandos de usuario) y di¬ 
versas interfaces gráficas de usuario (GUIs, Graphical User Interfaces] que se manejan a tra¬ 
vés de un ratón o una pantalla sensible al tacto. 

La fase de diseño también incluye el diseño de archivos o bases de datos que almacena¬ 
rán gran parte de los datos indispensables para los encargados de tomar las decisiones en la 
organización. Una base de datos bien organizada es el cimiento de cualquier sistema de in¬ 
formación. En esta fase el analista también interactúa con los usuarios para diseñar la salida 
(en pantalla o impresa) que satisfaga las necesidades de información de estos últimos. 

Finalmente, el analista debe diseñar controles y procedimientos de respaldo que prote¬ 
jan al sistema y a los datos, y producir paquetes de especificaciones de programa para los 
programadores. Cada paquete debe contener esquemas para la entrada y la salida, especifi¬ 
caciones de archivos y detalles del procesamiento; también podría incluir árboles o tablas de 
decisión, diagramas de flujo de datos, un diagrama de flujo de sistema, y los nombres y fun¬ 
ciones de cualquier rutina de código previamente escrita. 


DESARROLLO Y DOCUMENTACIÓN DEL SOFTWARE 

En la quinta fase del ciclo de vida del desarrollo de sistemas, el analista trabaja de manera 
conjunta con los programadores para desarrollar cualquier software original necesario. En¬ 
tre las técnicas estructuradas para diseñar y documentar software se encuentran los diagra¬ 
mas de estructura, los diagramas de Nassi-Shneiderman y el pseudocódigo. El analista se 
vale de una o más de estas herramientas para comunicar al programador lo que se requiere 
programar. 

Durante esta fase el analista también trabaja con los usuarios para desarrollar docu¬ 
mentación efectiva para el software, como manuales de procedimientos, ayuda en línea y si¬ 
tios Web que incluyan respuestas a preguntas frecuentes (FAQ, FrequentlyAsked Questions) 
en archivos "Léame" que se integrarán en el nuevo software. La documentación indica a los 
usuarios cómo utilizar el software y lo que deben hacer en caso de que surjan problemas de¬ 
rivados de este uso. 

Los programadores desempeñan un rol clave en esta fase porque diseñan, codifican y 
eliminan errores sintácticos de los programas de cómputo. Si el programa se ejecutará en un 
entorno de mainframe, se debe crear un lenguaje de control de trabajos (JCL, Job Control 
Lcinguagé). Para garantizar la calidad, un programador podría efectuar un repaso estructura¬ 
do del diseño o del código con el propósito de explicar las partes complejas del programa a 
otro equipo de programadores. 
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PRUEBA Y MANTENIMIENTO DEL SISTEMA 


Antes de poner el sistema en funcionamiento es necesario probarlo. Es mucho menos cos¬ 
toso encontrar los problemas antes que el sistema se entregue a los usuarios. Una parte de 
las pruebas las realizan los programadores solos, y otra la llevan a cabo de manera conjunta 
con los analistas de sistemas. Primero se realiza una serie de pruebas con datos de muestra 
para determinar con precisión cuáles son los problemas y posteriormente se realiza otra con 
datos reales del sistema actual. 

El mantenimiento del sistema de información y su documentación empiezan en esta 
fase y se llevan a cabo de manera rutinaria durante toda su vida útil. Gran parte del trabajo 
habitual del programador consiste en el mantenimiento, y las empresas invierten enormes 
sumas de dinero en esta actividad. Parte del mantenimiento, como las actualizaciones de 
programas, se pueden realizar de manera automática a través de un sitio Web. Muchos de los 
procedimientos sistemáticos que el analista emplea durante el ciclo de vida del desarrollo 
de sistemas pueden contribuir a garantizar que el mantenimiento se mantendrá al mínimo. 


EMPLEMENTACEÓN Y EVALUACIÓN DEL SISTEMA 

Esta es la última fase del desarrollo de sistemas, y aquí el analista participa en la implemen- 
tación del sistema de información. En esta fase se capacita a los usuarios en el manejo del 
sistema. Parte de la capacitación la imparten los fabricantes, pero la supervisión de ésta es 
responsabilidad del analista de sistemas. Además, el analista tiene que planear una conversión 
gradual del sistema anterior al actual. Este proceso incluye la conversión de archivos de for¬ 
matos anteriores a los nuevos, o la construcción de una base de datos, la instalación de equipo 
y la puesta en producción del nuevo sistema. 

Se menciona la evaluación como la fase final del ciclo de vida del desarrollo de sistemas 
principalmente en aras del debate. En realidad, la evaluación se lleva a cabo durante cada 
una de las fases. Un criterio clave que se debe cumplir es si los usuarios a quienes va dirigi¬ 
do el sistema lo están utilizando realmente. 

Debe hacerse hincapié en que, con frecuencia, el trabajo de sistemas es cíclico. Cuando 
un analista termina una fase del desarrollo de sistemas y pasa a la siguiente, el surgimiento 
de un problema podría obligar al analista a regresar a la fase previa y modificar el trabajo 
realizado. 

IMPACTO DEL MANTENIMIENTO 

Después de instalar un sistema, se le debe dar mantenimiento, es decir, los programas de 
cómputo tienen que ser modificados y actualizados cuando lo requieran. En la figura 1.4 se 
ilustra el tiempo promedio que se invierte en darle mantenimiento a un MIS típico. Según 
estimaciones, los departamentos invierten en mantenimiento de 48 a 60 por ciento del 
tiempo total del desarrollo de sistemas. Queda muy poco tiempo para el desarrollo de nue- 
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vos sistemas. Conforme se incrementa el número de programas escritos, también lo hace la 
cantidad de mantenimiento que requieren. 

El mantenimiento se realiza por dos razones. La primera es la corrección de errores del 
software. No importa cuan exhaustivamente se pruebe el sistema, los errores se cuelan en 
los programas de cómputo. Los errores en el software comercial para PC se documentan co¬ 
mo "anomalías conocidas", y se corrigen en el lanzamiento de nuevas versiones del software 
o en revisiones intermedias. En el software hecho a la medida, los errores se deben corregir 
en el momento que se detectan. 

La otra razón para el mantenimiento del sistema es la mejora de las capacidades del 
software en respuesta a las cambiantes necesidades de una organización, que por lo general 
tienen que ver con alguna de las siguientes tres situaciones: 

1. Con frecuencia, después de familiarizarse con el sistema de cómputo y sus capacidades, 

los usuarios requieren características adicionales. 

2. El negocio cambia con el tiempo. 

3. El hardware y el software cambian a un ritmo acelerado. 

La figura 1.5 ilustra la cantidad de recursos —por lo general tiempo y dinero— que se 
invierte en el desarrollo y mantenimiento de sistemas. El área bajo la curva representa la 
cantidad total invertida. Como puede apreciar, es probable que con el paso del tiempo el 
costo total del mantenimiento rebase el costo de desarrollar el sistema. Pasado un cierto 
tiempo es más factible realizar un nuevo estudio de sistemas, debido a que, evidentemente, 
el costo del mantenimiento continuo es mayor que el de la creación de un sistema de infor¬ 
mación completamente nuevo. 

En síntesis, el mantenimiento es un proceso continuo durante el ciclo de vida de un sis¬ 
tema de información. Después de instalar el sistema de información, por lo general el mante¬ 
nimiento consiste en corregir los errores de programación que previamente no se detecta¬ 
ron. Una vez corregidos estos errores, el sistema alcanza un estado estable en el cual ofrece 
un servicio confiable a sus usuarios. El mantenimiento durante este periodo podría consistir 
en eliminar algunos errores previamente no detectados y en actualizar el sistema con algu¬ 
nos cambios menores. Sin embargo, conforme pasa el tiempo y los negocios y la tecnología 
cambian, los esfuerzos de mantenimiento se incrementan de manera considerable. 


USO DE HERRAMIENTAS CASE 


A lo largo de este libro hacemos énfasis en la necesidad de un enfoque sistemático e integral 
para el análisis, diseño e implementación de sistemas de información. Reconocemos que pa¬ 
ra ser productivos, los analistas de sistemas deben realizar sus tareas de una manera organi¬ 
zada, precisa y minuciosa. Desde principios de la década de 1990, los analistas empezaron a 
beneficiarse de las herramientas de productividad, denominadas herramientas de Ingeniería 
de Software Asistida por Computadora (CASE, Computer-Aided Software Engineering), que 
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se crearon explícitamente para mejorar su trabajo rutinario mediante apoyo automatizado. 
De acuerdo con un estudio reciente, era más probable que los departamentos de sistemas 
de información con más de 10 empleados adoptaran las herramientas CASE que los depar¬ 
tamentos con menos empleados. Los sistemas, procedimientos y prácticas administrativas 
de las organizaciones podrían restringir la difusión de las herramientas CASE. Los analis¬ 
tas de sistemas se apoyan en estas herramientas, desde el principio hasta el fin del ciclo de 
vida, para incrementar la productividad, comunicarse de manera más eficiente con los usua¬ 
rios e integrar el trabajo que desempeñan en el sistema. 


RAZONES PARA EL USO DE LAS HERRAMIENTAS CASE 

Aumento en la productividad del analista Visible Analyst (VA) es una herramienta CASE 
que da al analista de sistemas la posibilidad de realizar planeación, análisis y diseño por me¬ 
dios gráficos, con el propósito de construir aplicaciones cliente-servidor y bases de datos 
complejas. Esta herramienta permite modelar los datos, procesos y objetos en diferentes for¬ 
matos. Visible Analyst genera información sobre el modelo en muchas formas distintas, in¬ 
cluyendo COBOL, C, Visual Basic, SQL y XML. (En el sitio Web de este libro encontrará 
ejercicios de VA parcialmente terminados para las Experiencias con HyperCase y el Caso 
de la CPU que se sigue en los capítulos de este libro.) 

Visible Analyst permite que sus usuarios dibujen y modifiquen diagramas con facili¬ 
dad. De esta manera, el analista es más productivo tan sólo con la reducción del tiempo 
considerable que se invierte en dibujar y corregir manualmente diagramas de flujo de datos 
hasta que tengan una apariencia aceptable. 

Un paquete de herramientas como Visible Analyst también mejora la productividad de 
grupos al dar a los analistas la posibilidad de compartir fácilmente el trabajo con otros 
miembros del equipo, quienes sólo tienen que abrir el archivo en sus PCs y revisar o modi¬ 
ficar lo que se haya hecho. Esta facilidad de compartir el trabajo reduce el tiempo necesario 
para reproducir diagramas de flujo de datos y distribuirlos entre los miembros del equipo. 
Por tanto, en vez de requerir una distribución rigurosa y un calendario de respuestas con fi¬ 
nes de retroalimentación, un paquete de herramientas permite a los miembros del equipo 
de análisis de sistemas trabajar con los diagramas siempre que lo necesiten. 

Las herramientas CASE también facilitan la interacción entre miembros de un equipo 
al hacer que la diagramación sea un proceso iterativo y dinámico más que uno en el cual los 
cambios causen molestia y se conviertan en un freno para la productividad. En este caso la 
herramienta CASE para dibujar y grabar diagramas de flujo de datos ofrece un registro de 
la evolución de las ideas del equipo en lo concerniente a los flujos de datos. 

Mejora de la comunicación analista-usuario Para que el sistema propuesto se concrete y 
sea útil en la práctica, es esencial una excelente comunicación entre analistas y usuarios du¬ 
rante todo el ciclo de vida del desarrollo de sistemas. El éxito de la futura implementación 
del sistema depende de la capacidad de analistas y usuarios para comunicarse de una mane¬ 
ra eficiente. Hasta el momento, de las experiencias de analistas que utilizan herramientas 
CASE se desprende que su uso fomenta una mayor y más eficiente comunicación entre 
usuarios y analistas. 

Analistas y usuarios por igual informan que las herramientas CASE ponen a su alcance 
un medio para comunicar aspectos del sistema durante su conceptualización. A través de 
apoyo automatizado que incluye salida en pantalla, los clientes pueden apreciar de inme¬ 
diato cómo están representados los flujos de datos y otros conceptos del sistema, y pueden 
solicitar correcciones o cambios que hubieran tomado demasiado tiempo con herramientas 
anteriores. 

El hecho de que un diagrama en particular sea considerado como útil por los usuarios 
o los analistas al final del proyecto es cuestionable. Lo importante es que este apoyo auto¬ 
matizado para muchas actividades de diseño del ciclo de vida es un medio para llegar a un 
fin al fungir como catalizador de la interacción analista-usuario. Los mismos argumentos 
que se utilizan para apoyar el rol de las herramientas CASE en el incremento de la produc¬ 
tividad son igualmente válidos en este escenario; es decir, las tareas de dibujo, reproducción 
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y distribución toman mucho menos tiempo, de tal forma que es más sencillo compartir el 
trabajo en progreso con los demás usuarios. 

Integración de las actividades del ciclo de vida La tercera razón para el uso de las herra¬ 
mientas CASE es integrar las actividades y proporcionar continuidad de una fase a la si¬ 
guiente durante todo el ciclo de vida del desarrollo de sistemas. 

Las herramientas CASE son especialmente útiles cuando una fase en particular del ci¬ 
clo de vida requiere varias iteraciones de retroalimentación y modificaciones. Recuerde que 
la intervención de los usuarios puede ser importante en cada una de las fases. La integración 
de actividades mediante el uso subyacente de tecnologías facilita a los usuarios la compren¬ 
sión de la manera en que se relacionan y dependen entre sí todas las fases del ciclo de vida. 

Evaluar de manera precisa los cambios en el mantenimiento La cuarta, y probablemente 
una de las razones más importantes para el uso de herramientas CASE, es que permiten a 
los usuarios analizar y evaluar el impacto de los cambios en el mantenimiento. Por ejemplo, 
el tamaño de un elemento como un número de cliente podría requerir alargarse. La herra¬ 
mienta CASE pueden generar referencias cruzadas de cada pantalla, informe y archivo en el 
cual sea utilizado el elemento, dando lugar a un plan de mantenimiento integral. 


HERRAMIENTAS CASE DE BAJO Y ALTO NIVEL 

Las herramientas CASE se clasifican como de bajo nivel, de alto nivel e integradas, estas úl¬ 
timas combinando las de alto y bajo nivel en un solo conjunto. A pesar de que los expertos 
difieren en los criterios que definen con precisión cuáles son las herramientas CASE de alto 
nivel y cuáles las de bajo nivel, podría ser útil clasificarlas con base en los usuarios a los que 
dan apoyo. Las herramientas CASE de alto nivel ayudan principalmente a los analistas y di¬ 
señadores, en tanto que las de bajo nivel son utilizadas con más frecuencia por programado- 
res y trabajadores que deben implementar los sistemas diseñados con herramientas CASE 
de alto nivel. 


HERRAMIENTAS CASE DE ALTO NIVEL 

Una herramienta CASE de alto nivel da al analista la posibilidad de crear y modificar el 
diseño del sistema. Toda la información relacionada con el proyecto se almacena en una 
enciclopedia denominada depósito CASE, una enorme colección de registros, elementos, 
diagramas, pantallas, informes e información diversa (véase la figura 1.6]. Con la informa¬ 
ción del depósito se podrían generar informes que muestren dónde está incompleto el dise¬ 
ño o dónde contiene errores. 

Las herramientas CASE de alto nivel también pueden apoyar la modelación de los re¬ 
querimientos funcionales de una organización, ayudar a los analistas y usuarios a definir el 
alcance de un proyecto determinado y a visualizar la forma en que el proyecto se combina 
con otras partes de la organización. Además, algunas herramientas CASE de alto nivel pue¬ 
den ayudar en la creación de prototipos de diseños de pantallas e informes. 


HERRAMIENTAS CASE DE BAJO NIVEL 


Las herramientas CASE de bajo nivel se utilizan para generar código fuente de computado¬ 
ra, eliminando así la necesidad de programar el sistema. La generación de código tiene va¬ 
rias ventajas: 

1. El sistema se puede generar más rápido que si se tuviera que escribir todos los progra¬ 
mas. No obstante, con frecuencia el periodo para familiarizarse con la metodología uti¬ 
lizada por el generador de código es muy largo, por lo que la generación del programa 
podría ser más lenta al principio. Además, es necesario ingresar por completo el diseño 
en el conjunto de herramientas, tarea que podría tomar un tiempo considerable. 

2. La generación de código reduce el tiempo invertido en el mantenimiento. No hay nece¬ 
sidad de modificar, probar y depurar los programas de computadora. En lugar de eso, al 
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Venias mensuales + 

Ventas anuales 




I 


DO WHILE NOT Fin de archivo 
Leer registro de artículo 
IF artículo tiene poco inventario 
Imprimir orden de compra 
Actualizar registro de artículo 
ENDIF 
EMDDO 




Diccionario de datos 
y lógica de procesos 



Requerimientos del sistema 

0 Agregar nuevos clientes : j 

• Identificar artículos de venta 

rapida y lenta. ' !¡¿ i 

• Ingresar órdenes de clientes 

• Consultar saldo de crédito :<?:• 3 
de cliente ¿O?*; 

• Mantener inventario adecuado 


Productos finales 

• Agregar pantalla de cliente 

« Informe de análisis de artículos 

• Panta|la para ingresar órdenes I Administración 

de clientes . .. ... :/ í'Ifá de! proyecto 

• Pantalla para investigación 

. co clientes ... ; 

• Programa para órdenes do 
compra a distribuidores 

• Pronóstico de temporada 


modificar el diseño CASE se vuelve a generar el código. Si se invierte menos tiempo en 
el mantenimiento, se tiene más tiempo para desarrollar nuevos sistemas y aligerar la 
acumulación de proyectos en espera de desarrollo. 

3. Más de un lenguaje de computadora, de tal manera que se facilita la migración de siste¬ 
mas de una plataforma, digamos de mainjrame, a otra, como una PC. Por ejemplo, la 
edición de VA para corporaciones puede generar código fuente en lenguajes de tercera 
generación como ANSÍ, COBOL o C. 

4. La generación de código ofrece una forma económica de ajustar los sistemas comercia¬ 
les de fabricantes de sistemas a las necesidades de la organización. Con frecuencia, la 
modificación de esta clase de software implica un esfuerzo tan grande que su costo es 
mayor al de la compra del mismo. Con el software de generación de código, la compra 
de un diseño CASE y un depósito CASE para la aplicación permite al analista modifi¬ 
car el diseño y generar el sistema de cómputo modificado. 

5. El código generado está libre de errores de programación. Los únicos errores potencia¬ 
les son los de diseño, los cuales se pueden minimizar produciendo informes de análisis 
CASE para garantizar que el diseño del sistema esté completo y correcto. 


EL ROL DEL ANALISTA DE SISTEMAS 











Aspectos de las 
especificaciones 

Aspectos del diseño del programa 


Errores 

de programación Errores de instalación 



Ciclo de vida del desarrollo de sistemas tradicional 


programa 


□efectos e inconsistencias 
Aspectos del diseño del diseño 



Ciclo de vida del desarrollo de sistemas CASE 


errores 



sistemas CASE y tradicional. 


La figura 1.7 ilustra los ciclos de vida del desarrollo de sistemas tradicional y CASE. 
Observe que las partes de codificación, prueba y depuración del programa se han elimina¬ 
do en el ciclo de vida CASE. 


iÑGEÑIERÍA INVERSAyIhÑmMÍEOTÍWÁRE 

La ingeniería inversa y la reingeniería de software son métodos para alargar la vida de pro¬ 
gramas anteriores, conocidos como software heredado. En ambos métodos se emplea soft¬ 
ware de reingeniería asistida por computadora (CARE, Computer-Assisted Reengineering] 
para analizar y reestructurar el código de computadora existente. En el mercado hay varios 
conjuntos de herramientas de ingeniería inversa. 

Observe que el término reingeniería se utiliza en numerosos contextos diferentes de in¬ 
geniería, programación y negocios. Con frecuencia se emplea para denotar "reingeniería de 
procesos de negocios", que es una forma de darle una nueva orientación a los procesos cla¬ 
ve de una organización. Los analistas de sistemas pueden desempeñar un rol importante en 
la reingeniería de procesos de negocios, puesto que muchos de los cambios requeridos sólo 
se pueden lograr mediante el uso de tecnología de información novedosa. 

La ingeniería inversa es lo opuesto a la generación de código. Como se ilustra en la figu¬ 
ra 1.8, el código fuente de la computadora es examinado, analizado y convertido en entidades 
para el depósito. El primer paso de la ingeniería inversa de software es cargar, en el conjun¬ 
to de herramientas, el código de programa existente (tal como se haya escrito en COBOL, C 
o cualquier otro lenguaje de alto nivel). Según el conjunto de herramientas de ingeniería in¬ 
versa que se utilice, el código es analizado y las herramientas producen algunos o todos los 
elementos siguientes: 

1. Estructuras de datos y elementos que describen los archivos y registros almacenados 
por el sistema. 

2. Diseños de pantallas, si el programa es en línea. 

3. Esquemas de informes para programas por lotes. 

4. Un diagrama de estructura que muestra la jerarquía de los módulos del programa. 

5. Diseño y relaciones de bases de datos. 
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Código fuente de la computadora: El conjunto de herramientas de Depósito CASE 

C, COBOL, Xbase... Ingeniería Inversa examina el 

código fuente de la computadora Se crea el depósito CASE, 

Programas de cómputo y produce un depósito CASE. Incluyendo diagramas de estructura, 

existentes cargados en el descripciones de registros y elementos 

conjunto de herramientas en el diccionario de datos, 

de ingeniería inversa. esquemas de pantalla y 

de informes. 


El diseño almacenado en el depósito podría modificarse o incorporarse en información de 
otro proyecto CASE. Cuando se terminan todas las modificaciones, el nuevo código del sis¬ 
tema puede volver a generarse. La reingeniería se refiere al proceso completo de convertir 
el código de programa al diseño CASE, modificar el diseño y volver a generar el nuevo có¬ 
digo de programa. 

Son varias las ventajas que se consiguen al utilizar un conjunto de herramientas de in¬ 
geniería inversa: 

1. Reducción del tiempo requerido para el mantenimiento del sistema, con lo cual queda 
más tiempo para nuevos desarrollos. 

2. Se genera documentación, que podría haber sido inexistente o mínima en los progra¬ 
mas anteriores. 

3. Se crean programas estructurados a partir de código de computadora no estructurado o 
pobremente estructurado. 

4. Los cambios futuros al mantenimiento son más sencillos, porque se pueden realizar al 
nivel del diseño más que al nivel del código. 

5. Es posible analizar el sistema con el fin de eliminar porciones sin utilizar de código de 
computadora, el cual aún podría estar presente en programas anteriores a pesar de que 
las revisiones hechas al programa a lo largo de los años lo hayan vuelto obsoleto. 


ANALISIS' YDIS® DESISTÍ 

El análisis y diseño orientado a objetos es un enfoque cuyo propósito es facilitar el desarrollo _ 
de sistemas que deben cambiar con rapidez en respuesta a entornos de negocios dinámicos. 
El capítulo 19 le ayuda a entender el análisis y diseño de sistemas orientados a objetos, en 
qué difiere del enfoque estructurado del SDLC y bajo qué circunstancias es apropiado uti¬ 
lizar un enfoque orientado a objetos. 

Es difícil trabajar bien con técnicas orientadas a objetos en situaciones en las cuales 
sistemas de información complicados requieren mantenimiento, adaptación y rediseño de 
manera continua. Los enfoques orientados a objetos utilizan el estándar de la industria pa¬ 
ra la modelación de sistemas orientados a objetos, el lenguaje unificado de modelación 
[UML, UnifiedModelingLcinguagé), para analizar un sistema en forma de modelo de casos 
de uso. 

La programación orientada a objetos difiere de la programación tradicional de procedi¬ 
mientos en que la primera examina los objetos que conforman un sistema. Cada objeto es 
una representación en computadora de alguna cosa o suceso real. Los objetos pueden ser 
clientes, artículos, pedidos, etc. Los objetos se representan y agrupan en clases, que son óp¬ 
timas para su reutilización y mantenimiento. Una clase define el conjunto de atributos y 
comportamientos que comparten los objetos que ésta contiene. 
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PROGRAMACION EXTREMA Y OTRAS METODOLOGIAS ALTERNAS 


Aunque este libro se enfoca en la metodología que actualmente se utiliza de manera más 
amplia, en ocasiones el analista tendrá que reconocer que la organización se podría benefi¬ 
ciar de una metodología alterna. Quizá un proyecto de sistemas con un enfoque estructurado 
haya fallado, o quizá las subculturas que existen en la organización, compuestas por diferen¬ 
tes grupos de usuarios, parezcan más proclives a utilizar un método alterno. En un espacio 
tan breve no podríamos analizar adecuadamente estos métodos alternos, que merecen y han 
sido explicados en sus propios libros e investigaciones. Sin embargo, al mencionarlos aquí 
esperamos que usted tome conciencia de que, bajo ciertas circunstancias, su organización 
podría requerir una alternativa o complemento para un análisis y diseño estructurado y para 
el ciclo de vida del desarrollo de sistemas. 

La programación extrema (XP, Extreme Programming) es un enfoque para el desarrollo 
de software que utiliza buenas prácticas de desarrollo y las lleva a los extremos. Se basa en 
valores, principios y prácticas esenciales. Los cuatros valores son la comunicación, la simpli¬ 
cidad, la retroalimentación y la valentía. Recomendamos a los analistas de sistemas que 
adopten estos valores en todos los proyectos que emprendan, no sólo cuando recurran a 
medidas de programación extrema. 

Durante la fase de terminación de un proyecto, con frecuencia es necesario realizar 
ajustes en la administración del mismo. En el capítulo 3 veremos que XP puede garantizar 
la terminación exitosa de un proyecto ajustando recursos importantes como el tiempo, el 
costo, la calidad y el alcance. Cuando estas cuatro variables de control se incluyen adecua¬ 
damente en la planeación, se propicia un equilibrio entre los recursos y las actividades re¬ 
queridas para completar el proyecto. 

El llevar las prácticas de desarrollo al extremo es más recomendable cuando se siguen 
prácticas propias de XP. En el capítulo 6 describimos cuatro prácticas esenciales de XP: la 
liberación limitada, la semana de trabajo de 40 horas, alojar a un cliente en el sitio y el uso 
de la programación en parejas. A primera vista estas prácticas parecen extremas, pero como 
observará, podemos aprender algunas lecciones valiosas al incorporar muchos de estos valo¬ 
res y prácticas de XP en los proyectos de análisis y diseño de sistemas. 

La creación de prototipos (que es diferente a la creación de prototipos que veremos 
en el capítulo 6) es uno de los métodos alternos más populares, junto con ETH1CS, el en¬ 
foque de usar un campeón del proyecto, la Metodología Soft Systems y Multiview. La 
creación de prototipos, concebida originalmente en otras disciplinas y aplicada a los siste¬ 
mas de información, surgió como respuesta a los extensos periodos de desarrollo asociados 
con el enfoque del ciclo de vida del desarrollo de sistemas y a la incertidumbre que existe con 
frecuencia en relación con los requerimientos de los usuarios. ETHICS, por su parte, se 
presentó como una metodología socio-técnica que combina soluciones sociales y técnicas. 
El enfoque de usar un campeón del proyecto, un concepto tomado de la mercadotecnia, 
adopta la estrategia de involucrar a una persona clave de cada área donde tiene influencia 
el sistema para garantizar el éxito del mismo. La Metodología Soft Systems fue concebida 
como una manera de modelar un mundo muchas veces caótico mediante el uso de "imáge¬ 
nes ricas", ideogramas que captan los relatos característicos de una organización. Multi¬ 
view se propuso como una forma de organizar y utilizar elementos de diversas metodolo¬ 
gías en competencia. 



RESUMEN 


La información se puede considerar como un recurso organizacional. Como tal, se debe 
manejar con cuidado, al igual que los demás recursos. La disponibilidad de gran poder de 
cómputo en las organizaciones ha propiciado una explosión de información y, en conse¬ 
cuencia, se debe prestar mayor atención al manejo de la información generada. 
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EXPERIENCIA CON HYPERCAS ES? 


"Bienvenido a Maple Ridge Engineering, al que en.adelante llamaremos MRE. Esperamos 
que disfrute su trabajo de consultor de sistemas para nosotros. A pesar de que he trabajado 
aquí durante cinco años en diferentes actividades, recién fui asignado para fungir como apo¬ 
yo administrativo para Snowdcn Evans, el jefe del nuevo Departamento de Capacitación y 
Administración de Sistemas. Ciertamente somos un grupo heterogéneo. Conforme se fami¬ 
liarice con la compañía, asegúrese de aprovechar todos sus conocimientos, tanto técnicos 
como relativos a las personas, para entender cómo somos e identificar los problemas y con¬ 
flictos relacionados con nuestros sistemas de información que usted considere susceptibles 
de arreglar".. .:-; f 

"Para ponerlo al tanto, le diré que Maple Ridge Engineering es una compañía de inge¬ 
niería médica de mediano tamaño. El año pasado nuestros ingresos rebasaron,287 millones 
de dólares. Empleamos alrededor de 335 personas. Hay cerca de 150 empleados administra¬ 
tivos, así como personal directivo y de oficinas, como yo. y aproximadamente 75 profesio¬ 
nistas, como ingenieros, médicos y analistas de sistemas: y cerca de 110 empleados como di¬ 
bujantes,y técnicos", i : • 

"Hay cuatro oficinas. A través de HyperCase, usted nos visitará en nuestras oficinas cen¬ 
trales en Maple Ridge, Tennessee. Tenemos otras tres sucursales al sur dé Estados Unidos: 
Atlanta, Georgia; Charlotte, Carolina del Norte; y Nüeva Orleáns, Luisiana./Nos dará gusto 
que nos visite". • . 

"Por el moméntó, explore HyperCase con Nestcape Navigator o Microsoft Internet Ex¬ 
plorer". , , ' "■ 

"Para aprender más sobre Maple Ridge Engineering como compañíá, o para saber cómo 
entrevistar a nuestros empleados, quién utilizará los sistemas que usted diseñe y cómo son 
sus oficinas dentro de nuestra compañía, visite el sitio Web de este libro, y seleccione el 
vínculo HyperCase! Al desplegarse la pantalla de HyperCase, elija Start e ingresará a la re¬ 
cepción de Maple Ridge Engineering. A partir de aquí, puedé empezar de inmediato sü tra¬ 
bajo de consultoría". 

Este sitio Web contiene información útil pára él proyecto y archivos que usted puede 
bajar a su computadora. Uno de los archivos contiene una serie de archivos de datos de Vi¬ 
sible Analyst para utilizarse en HyperCase. Estos archivos incluyen una serie:parcialmente 
construida de diagramas de flujo de datos, diagramas de entidad-relación y el depósito CASE. 
El sitio Web de HyperCase támbién contiene ejercicios adicionales. HyperCase está diseña¬ 
do para facilitar su exploración, ásí que no ignore cualquier objeto o pista que encuentre en 
la página Web. 



Los analistas de sistemas recomiendan, diseñan y dan mantenimiento a diversos tipos 
de sistemas, como los sistemas de procesamiento de transacciones (TPS), sistemas de auto¬ 
matización de la oficina (CAS), sistemas de trabajo del conocimiento (KWS) y sistemas de 
información gerencial [MIS). También crean sistemas orientados a la toma de decisiones, 
como los sistemas de apoyo a la toma de decisiones (DSS), sistemas expertos (ES), sistemas 
de apoyo a la toma de decisiones en grupo (GDSS), sistemas de trabajo colaborativo apoyados 
por computadora (CSCWS) y sistemas de apoyo a ejecutivos [ESS). Muchas aplicaciones 
se conciben originalmente para, o se migran a, la Web para apoyar el comercio electrónico. 

El diseño y análisis de sistemas es un enfoque sistemático para identificar problemas, 
oportunidades y objetivos; para analizar los flujos de información de las organizaciones, y 
para diseñar sistemas de información computarizados destinados a solucionar problemas. 
Los analistas de sistemas se ven precisados a desempeñar diversos roles durante el transcurso 
de su trabajo. Algunos de estos roles son: (1) consultor extemo para el negocio, (2) experto de 
apoyo técnico dentro de un negocio y (3) agente de cambio en situaciones tanto internas 
como externas. 














Los analistas poseen un amplio rango de habilidades. En primer lugar, y más importan¬ 
te, el analista es un solucionador de problemas; alguien que disfruta el reto de analizar un 
problema e idear soluciones factibles. El analista de sistemas requiere habilidades de comu¬ 
nicación que le permitan relacionarse de manera significativa con diversas clases de gente 
diariamente, así como habilidades de computación. El involucramiento del usuario final es 
crítico para el éxito del proyecto. 

Los analistas actúan de manera sistemática. El marco para este enfoque sistemático lo 
ofrece el ciclo de vida del desarrollo de sistemas (SDLC]. Este ciclo de vida se puede dividir 
en siete fases secuenciales, aunque en realidad las fases se interrelacionan y con frecuencia 
se llevan a cabo de manera simultánea. Las siete fases son: identificación de problemas, 
oportunidades y objetivos; determinación de los requerimientos de información; análisis de 
las necesidades del sistema; diseño del sistema recomendado; desarrollo y documentación 
del software; prueba y mantenimiento del sistema, e implementación y evaluación del sistema. 

Los paquetes de software automatizados, basados en PC, para el análisis y diseño de sis¬ 
temas se conocen como herramientas de Ingeniería de Software Asistida por Computadora 
(CASE). Las cuatro razones para adoptarlas herramientas CASE son: incrementar la produc¬ 
tividad del analista, mejorar la comunicación entre analistas y usuarios, integrar las activida¬ 
des del ciclo de vida, y analizar y valorar el impacto de los cambios en el mantenimiento. Los 
analistas también emplean enfoques de reingeniería asistida por computadora (CARE) para 
realizar ingeniería inversa de software y reingeniería con el propósito de extender la vida 
útil del software heredado. 

El análisis orientado a objetos (OOA) y el diseño orientado a objetos (OOD) constitu¬ 
yen un enfoque distinto de desarrollo de sistemas. Estas técnicas se basan en los conceptos 
de la programación orientada a objetos, que han sido codificados en UML, un lenguaje es¬ 
tandarizado de modelación en el cual los objetos generados no sólo incluyen código referen¬ 
te a los datos sino también instrucciones acerca de las operaciones que se realizarán sobre 
los datos. 

Cuando la situación particular de una organización así lo requiera, el analista podría 
dejar el SDLC y probar una metodología alterna. Un enfoque, denominado programación 
extrema (XP), lleva al límite las prácticas de análisis y diseño. La creación de prototipos, 
ETHICS, el uso de un campeón del proyecto, la Metodología Soft Systems y Multiview son 
enfoques de desarrollo que ofrecen perspectivas diferentes. 


PALABRAS Y FRASES CLAVE 


agente de cambio 
análisis orientado a objetos (OOA) 
análisis y diseño de sistemas 
análisis y diseño de sistemas orientado 
a objetos (0-0) 
analista de sistemas 
aplicaciones de comercio electrónico 
asistente digital personal (PDA) 

CARE (reingeniería asistida por 
computadora) 

ciclo de vida del desarrollo de sistemas 
(SDLC) 

comercio móvil 
consultor de sistemas 
creación de prototipos 
depósito CASE 

desarrollo rápido de aplicaciones (RDA) 
diseño orientado a objetos (OOD) 
enfoque de uso de un campeón del 
proyecto 
ETHICS 


experto en soporte técnico 
groupware 
herramientas CASE 

información generada por computadora 
Ingeniería de Software Asistida por 
Computadora (CASE) 
ingeniería inversa de software 
inteligencia artificial (Al) 
lenguaje unificado de modelación 
(UML) 

mantenimiento de generación de código 
Metodología Soft Systems 
migración de sistemas 
Multiview 

programación extrema (XP) 
reingeniería 

sistemas de apoyo a ejecutivos (ESS) 
sistemas de apoyo a la toma de 
decisiones (DSS) 
sistemas de apoyo a la toma de 
decisiones en grupo (GDSS) 
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sistemas de automatización de la 
oficina (OAS) 

sistemas de información gerencial 
(MIS) 

sistemas de planeación de recursos 
empresariales (ERP) 
sistemas de procesamiento de 
transacciones (TPS) 


sistemas de trabajo colaborativo 
apoyado por computadora (CSCWS) 
sistemas de trabajo del conocimiento 
(KWS) 

sistemas expertos 
sistemas Web 
software de código abierto 
software heredado 


PREGUNTAS DE REPASO 

1. Describa por qué es mejor considerar a la información como un recurso de la organiza¬ 
ción más que como un subproducto derivado de los negocios. 

2. Defina lo que significa un sistema de procesamiento de transacciones. 

3. Explique la diferencia entre los sistemas de automatización de la oficina (OAS) y los 
sistemas de trabajo del conocimiento (KWS]. 

4. Compare la definición de sistemas de información gerencial (MIS) y la de sistemas de 
apoyo a la toma de decisiones (DSS). 

5. Defina el concepto sistemas expertos. ¿En qué son diferentes los sistemas expertos y los 
sistemas de apoyo a la toma de decisiones? 

6. Enumere los problemas de interacción grupal que están destinados a resolver los sistema 
de apoyo a la toma de decisiones en grupo (GDSS) y los sistemas de trabajo colabora¬ 
tivo apoyados por computadora (CSCWS). 

7. ¿Cuál es el término más común, CSCWS o GDSS? Explique su respuesta. 

8. Defina el concepto comercio móvil [m-commercé). 

9. Enumere las ventajas de implementar aplicaciones en la Web. 

10. ¿Cuál es la razón preponderante para diseñar sistemas ERP? 

11. Defina el significado de software de código abierto. 

12. Enumere las ventajas de utilizar técnicas de análisis y diseño de sistemas al desarrollar 
sistemas de información computarizados para negocios. 

13. Mencione tres roles que debe desempeñar un analista de sistemas. Dé una definición de 
cada rol. 

14. ¿Qué cualidades personales son de utilidad para el analista de sistemas? Enumérelas. 

15. Mencione y describa brevemente las siete fases del ciclo de vida del desarrollo de siste¬ 
mas (SDLC). 

16. ¿En qué consiste el desarrollo rápido de aplicaciones (RAD)? 

17. Defina ingeniería inversa de software y reingeniería en el contexto de reingeniería asis¬ 
tida por computadora (CARE). 

18. Mencione las cuatro razones para adoptar herramientas CASE. 

19. ¿Cuáles son los cuatro valores de la programación extrema? 

20. Defina los conceptos análisis orientado a objetos y diseño orientado a objetos. 

21. ¿QuéeselUML? 
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EiPIEZA EL CASO 




Un día soleado y caluroso de fines de octubre. Chip Puller estacionó su automóvil y se en¬ 
caminó a su oficina en la Central Pacific University. Era agradable la sensación de comenzar 
como analista de sistemas, y esperaba con ansia el momento de conocer a sus compañeros. 

En la oficina, Anna Liszt se presenta a sí misma. "Nos han asignado para trabajar como 
equipo en un nuevo proyecto. Puedo ponerte al tanto de los detalles y después hacemos un 
recorrido por las instalaciones." 

"Me parece bien", contesta Chip. "¿Cuánto tiempo llevas trabajando aquí?" 

"Alrededor de cinco años", responde Anna. "Empecé como analista programador, pero 
en los últimos años me he dedicado al análisis y el diseño. Espero que encontremos algunos 
métodos para incrementar nuestra productividad." 

"Habíame acerca del nuevo proyecto", dice Chip. 

"Bueno", contesta Anna, "al igual que muchas organizaciones, tenemos un gran número 
de microcomputadoras con diferentes paquetes de software instalados. En 1980 había pocas 
microcomputadoras y una colección dispersa de software, pero se han incrementado rápida¬ 
mente en los últimos años. El sistema actual utilizado para mantener el software y el hard¬ 
ware ha sido sobrepasado." 

"¿Qué hay de los usuarios? ¿A quién debo conocer? ¿Quién crees que sea importante 
que nos ayude con el nuevo sistema?", pregunta Chip. 

"Conocerás a todos, pero recientemente conocí a algunas personas importantes, y te di¬ 
ré lo que aprendí de ellas para que las recuerdes cuando te reúnas con ellas. 

"Dot Matricks es gerente de todos los sistemas de microcomputadoras de la Central Pa¬ 
cific. Al parecer podemos trabajar bien en conjunto. Ella es muy competente. Realmente le 
agrada mejorar la comunicación entre usuarios y analistas." 

"Será un placer conocerla", especula Chip. 

"Luego está Mike Crowe, el experto en mantenimiento de las microcomputadoras. El 
es el más amable, pero está demasiado ocupado. Necesitamos ayudarle a aligerar su carga. 
Cher Ware es compañera de Mike. Ella es muy liberal, pero no me malinterpretes, ella co¬ 
noce su trabajo", dice Anna. 

"Debe ser divertido trabajar con ella", comenta Chip. 

"Es probable", coincide Anna. "También conocerás a la analista financiera, Paige Pryn- 
ter. Aún no la conozco." 

"Tal vez yo pueda ayudarte", dice Chip. 

"Por último, deberías —es decir, deberás— conocer a Hy Perteks, quien dirige bastante 
bien el Centro de Información. A él le encantaría que lográramos integrar las actividades de 
nuestro ciclo de vida." 

"Suena prometedor", dice Chip. "Creo que la voy a pasar bien aquí." 

EJERCICIO 

E-l. De la conversación preliminar que sostuvieron Chip y Anna, ¿en cuáles de los ele¬ 
mentos que mencionaron se podrían aplicar las herramientas CASE? 


EL ROL DEL ANALISTA DE SISTEMAS 










EL ESTILO ORGANIZACIONAL 
Y SU IMPACTO 
EN LOS SISTEMAS 
DE INFORMACIÓN 


■ r- 








OBJETIVOS DE APRENDIZAJE 

Una vez que haya dominado el material de este capítulo, podrá: 

1. Entender que las organizaciones son sistemas y que el analista debe analizarlas desde 
una perspectiva sistémica.- ■ 

: 2;: Describir sistemas de manera gráfica mediante diagramas de flujo de datos de contexto 
y modelos entidad-relación. 

: 3. Reconocer que los diversos niveles de administración requieren sistemas diferentes. 

4 Entender que la cultura organizacional influye en el diseño de los sistemas de información. 


Para analizar y diseñar sistemas de información apropiados, los analistas de sistemas tienen 
que visualizar a las organizaciones dónde trabajan como sistemas formados por las interac¬ 
ciones de tres fuerzas principales; los niveles de administración, el diseño de las organizado-:: 
nes y las culturas, orgánizacionales. ; -i 

' Las organizaciones son grandes sistemas compuestos por subsistemas interrelacionados. 
Los subsistemas reciben la influencia de tres amplios niveles de tomadores de decisiones ad- : 
ministrátivás,[operaciones, administración de nivel medio y administración estratégica] que 
dividen horizoritalmeñte el sistema organizacional. Todas las culturas y subculturas qrgani- 
zacionales influyen en la forma en que se interrelacionan los individuos de los’subsistemas. 
En este capítulo se tratan estos temas y.siis implicaciones para el desarrollo de los sistemas de 
información. 


LAS ORGANIZACIONES COMO SISTEMAS 

Las organizaciones se consideran como sistemas diseñados,para cumplir metas y objetivos 
predeterminados con la intervención de la geñte y otros recursos de que disponen. Las or¬ 
ganizaciones se componen de sistemas más pequeños e interrelacionados (departamentos, 
unidades, divisiones, etc.) qué se encargan dé funciones especializadas: Entre las funciones 
comunes están la contabilidad, el marketing, la producción, el procesamiento de datos y la 
administración. Con el tiempo, las funciones especializadas (sistemas más pequeños) sé 
reintegran a través de diversos mecanismos para dar forma a un todo organizacional eficiente. 

La importancia de coñsidéíar a las organizaciones corno sistemas complejos radica én 
que los principios que se aplican a los sistemas permiten formarsé uriá idea de la manera 
en que funcionan las Organizaciones. Es mtiy importante considerar á la organización como 
un todo, con el fin de averiguar adecuadamente los requerimientos de información y de di- 




























señar sistemas de información apropiados. Todos los sistemas se componen de subsistemas 
(que incluyen a los sistemas de información); por lo tanto, al estudiar una organización, 
también examinamos cómo influyen los sistemas más pequeños y cómo funcionan. 

ENTERRELACIÚN E INTERDEPENDENCIA DE LOS SISTEMAS 

Todos los sistemas y subsistemas se interrelacionan y son interdependientes. Esta situación 
tiene importantes implicaciones tanto para las organizaciones como para los analistas de sis¬ 
temas encargados de contribuir a que aquéllas consigan de la mejor manera sus metas. 
Cuando se cambia o elimina un elemento de un sistema, el resto de los elementos y subsis¬ 
temas del sistema también experimentan cambios importantes. 

Por ejemplo, suponga que los administradores de una organización deciden despedir a 
las secretarias personales y reemplazar sus funciones con PCs conectadas en red. Esta deci¬ 
sión tiene la posibilidad de afectar significativamente no sólo a las secretarias y a los admi¬ 
nistradores, sino también a todos los miembros de la organización que hayan establecido 
redes de comunicaciones con las recién despedidas secretarias. 

Todos los sistemas procesan información proveniente de sus entornos. Por naturaleza, 
los procesos cambian o transforman esa información entrante en información de salida. 
Cuando examine un sistema, revise lo que se esté cambiando o procesando. Si nada se está 
cambiando, quizá lo que esté analizando no sea un proceso. Entre los procesos típicos de un 
sistema están la revisión, la actualización y la impresión. 

Otro aspecto que hace a las organizaciones parecidas a los sistemas es que todos los sis¬ 
temas están delimitados por fronteras que los separan de sus entornos. Las fronteras de una 
organización existen en un continuo que va de extremadamente permeable a casi imper¬ 
meable. Para continuar evolucionando y sobrevivir, las organizaciones deben tener primero 
la capacidad de allegarse gente, materias primas e información al interior de sus fronteras 
(entradas), y después, de intercambiar sus productos, servicios o información terminados 
con el mundo exterior (salidas). 

La retroalimentación constituye un mecanismo de control del sistema. Como sistemas, 
todas las organizaciones utilizan la planeación y el control para administrar con eficacia sus 
recursos. La figura 2.1 muestra cómo las salidas del sistema se emplean como retroalimen¬ 
tación para comparar el desempeño con las metas. A su vez, esta comparación es útil para 
que los administradores establezcan metas más específicas como entradas. Un ejemplo es 
una compañía que fabrica trajes deportivos con franjas rojas, blancas y azules, al igual que 
trajes en un solo color, gris metálico. La compañía se percata de que un año después de las 
olimpiadas se venden muy pocos trajes de franjas. Los gerentes de producción utilizan esta 
información como retroalimentación para decidir la cantidad que deben producir de cada 
color. En este ejemplo la retroalimentación es útil en la planeación y el control. 

Sin embargo, el sistema ideal es aquel que se corrige y regula por sí mismo de tal manera 
que no es necesario tomar decisiones sobre situaciones comunes. Un ejemplo lo constituye 
un sistema de información computarizado para planear la producción que toma en cuenta 
la demanda actual y la proyectada y propone una solución como salida. Un fabricante de ro¬ 
pa italiano que vende sus productos en Estados Unidos tiene un sistema similar a éste. La 
compañía fabrica la mayoría de sus suéteres en color blanco; averigua, mediante su sistema 
de información de inventarios computarizado, qué colores se venden más, y a continuación 
tiñe los suéteres en estos colores inmediatamente antes de embarcarlos. 






La retroalimentación llega desde el interior de la organización y desde los entornos que 
la circundan. Cualquier cosa externa a las fronteras de la organización se considera como un 
entorno. Numerosos entornos, con diversos grados de estabilidad, constituyen el medio en 
el cual se desenvuelve la organización. 

Entre estos entornos se encuentran: (1) el entorno de la comunidad en la cual se locali¬ 
za físicamente la organización, conformado por el tamaño de su población y su perfil demo¬ 
gráfico, el cual incluye factores como la educación y el ingreso promedio; (2) el entorno 
económico, influido por factores de mercado, como la competencia, y (3) el entorno político, 
controlado por los gobiernos estatales y locales. Aunque la organización puede realizar su 
planeación tomando en cuenta los cambios en el estado del entorno, con frecuencia no pue¬ 
de controlar directamente estos cambios. 

El concepto de apertura o cerrazón interna de las organizaciones es similar y está rela¬ 
cionado con la permeabilidad externa de las fronteras. La apertura y la cerrazón también 
existen en un continuo, ya que no hay una organización que sea absolutamente abierta o 
completamente cerrada. 

La apertura se refiere al flujo de información libre dentro de la organización. Los sub¬ 
sistemas como los departamentos creativos o de arte con frecuencia se representan como 
abiertos, con un flujo de ideas libre entre los participantes y muy pocas restricciones acerca 
de quién obtiene qué información en un momento determinado cuando un proyecto crea¬ 
tivo está en sus etapas tempranas. 

En el extremo opuesto del continuo podría encontrarse una unidad del departamento 
de defensa asignada a un proyecto ultra secreto relacionado con la seguridad nacional. Cada 
persona necesita autorización, la información oportuna es una necesidad y el acceso a la in¬ 
formación se realiza sobre la base de "necesidad de saber". Este tipo de unidad está regida 
por una gran cantidad de reglas. 

Al utilizar y enlazar sistemas para comprender las organizaciones podemos entender el 
concepto de sistemas compuestos de subsistemas; su interrelación e interdependencia; la 
existencia de fronteras que permiten o impiden la interacción entre diversos departamentos 
y elementos de otros subsistemas y entornos; y la existencia de entornos internos caracteri¬ 
zados por grados de apertura y cerrazón, que pueden variar entre departamentos, unidades 
o incluso proyectos. 


ORGANIZACIONES VIRTUALES Y EQUIPOS VIRTUALES 

No todas las organizaciones o partes de éstas se encuentran visibles en una ubicación físi¬ 
ca. En la actualidad, organizaciones completas o unidades de éstas pueden tener compo¬ 
nentes virtuales que les permiten cambiar su configuración para adaptarse a proyectos 
cambiantes o a demandas del mercado. Las empresas virtuales utilizan redes de computado¬ 
ras y tecnología de telecomunicaciones para reunir, por medios electrónicos, a individuos 
con habilidades específicas con el propósito de que trabajen en proyectos que no se locali¬ 
zan físicamente en el mismo lugar. La tecnología de información hace posible la coordina¬ 
ción de los miembros de estos equipos remotos. Con frecuencia, en organizaciones recién 
establecidas, surgen repentinamente equipos virtuales; sin embargo, en algunos casos, las 
organizaciones de trabajadores remotos han sido capaces de triunfar sin las inversiones tra¬ 
dicionales en infraestructura. 

Entre los beneficios potenciales para las organizaciones virtuales se encuentra la posi¬ 
bilidad de reducir costos derivados de instalaciones físicas, una respuesta más rápida a las 
necesidades de sus clientes y contribuir a que sus empleados virtuales satisfagan sus com¬ 
promisos familiares con sus hijos o sus padres ancianos. Por cierto, aún está abierto a in¬ 
vestigación y discusión qué tan importante será cumplir las necesidades sociales de los 
trabajadores virtuales. Un ejemplo de una necesidad de identificación tangible con una 
cultura es el que surge entre los estudiantes de una universidad virtual en línea, sin cam¬ 
pus físico [ni equipos deportivos], que insisten en adquirir artículos como sudaderas, ta¬ 
zas para el café y banderines con el logotipo de la universidad virtual. Estos artículos son 
objetos culturales significativos que las universidades físicas han ofrecido durante mucho 
tiempo. 
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P O R T UNIDAD DE CONSULTORÍA 2. 1 


LA E DE VITAMINA E SIGNIFICA COMERCIO ELECTRONICO 


"Nuestras tiendas minoristas y nuestra división de ventas por correo 
son bastante prósperas 1 ', dice Bill Berry, uno de los propietarios de Ma¬ 
rathón Vitamin Shops, "pero para luchar contra la competencia debemos 
establecer un sitio Web de comercio electrónico". Su padre, y copropie¬ 
tario, exclama: "Estoy de acuerdo, pero, ¿por dónde empezamos?" Por 
supuesto, el mayor de los Berry sabía que no se trataba tan sólo de esta¬ 
blecer un sitio Web y pedirle a los clientes que envien sus pedidos por co¬ 
rreo electrónico a la tienda minorista. Identificó ocho partes diferentes 
para el comercio electrónico y se dio cuenta de que, en conjunto, confor¬ 
maban un sistema más grande. En otras palabras, todas las partes te¬ 
nían que funcionar juntas para crear un paquete sólido. La siguiente es 
su lista de elementos esenciales para el comercio electrónico: 

1. Atraer a los clientes a un sitio Web de comercio electrónico. 

2. Proporcionar información a los clientes acerca de los productos y 
servicios que se ofrecen. 

3. Dar a los clientes la facilidad de personalizar productos en línea. 

4. Completar las transacciones con los clientes. 

5. Aceptar diversas formas de pago de los clientes. 


6. Dará los clientes apoyo técnico a través del sitio Web, posteriora la 
venta. 

7. Organizaría entrega de productos y servicios. 

8. Personalizarla apariencia del sitio Web para los diversos clientes. 

Bill Berry leyó la lista y la observó durante unos momentos. "Es evi¬ 
dente que el comercio electrónico es más complejo de lo que creí", dijo. 
Usted puede ayudar de las siguientes maneras a los propietarios de Ma¬ 
rathón Vitamin ShopS: 

1. Elabore una lista de los elementos que se interrelacionen o sean ¡n- 

terdependientes. '• ; - 

2. Determiné las fronteras del sistema. Es decir, redacté un párrafo con 
sü opinión sobre cuáles elementos son críticos para Marathón Vita¬ 
min Shops y cuáles se pueden dejar para una posterior exploración. 

3. Sugiera cuáles/elementos deberían manejarse de manera interna y 
cuáles podrían subcontratarse a otra empresa que tenga mejores 
recursos para manejarlos. Justifique sus sugerencias eri dos párra- 

,.: fos, uno para lastáreas internas y otro para las subcontratadas. 


En la actualidad, muchos equipos de análisis y diseño de sistemas tienen capacidad pa¬ 
ra trabajar de manera virtual, y de hecho, muchos de ellos abrieron el camino para que otros 
tipos de empleados imitaran esta forma virtual de realizar el trabajo. Algunas aplicaciones 
dan la facilidad al analista que ofrece asistencia técnica a través de la Web para "ver" la con¬ 
figuración de software y hardware del usuario que solicita la asistencia, generando de esta 
manera un equipo virtual temporal integrado por el analista y el usuario. 

ADOPCIÓN DE UNA PERSPECTIVA DE SISTEMAS 

El hecho de adoptar una perspectiva de sistemas da a los analistas de sistemas la oportunidad 
de empezar a clarificar y comprender los diversos aspectos con los que se enfrentarán. Es 
importante que los miembros de los subsistemas se den cuenta de que su trabajo está inte¬ 
rrelacionado. En la figura 2.2 se puede apreciar que las salidas de los subsistemas de produc¬ 
ción sirven como entradas para marketing, y que las salidas de marketing son nuevas entra¬ 
das para producción. Ninguno de los subsistemas podría alcanzar cabalmente sus metas sin 
el otro. 

Los problemas surgen cuando cada gerente tiene un concepto diferente de la importan¬ 
cia de su subsistema funcional. En la figura 2.3 se ilustra cómo la perspectiva individual del 
gerente de marketing concibe que este departamento es el motor del negocio, y que las de¬ 
más áreas funcionales están interrelacionadas pero no tienen una importancia fundamental. 
De igual manera, la perspectiva de un gerente de producción coloca a este departamento 
como el centro del negocio, y que impulsa a las demás áreas funcionales. 

La relativa importancia de las áreas funcionales tal como la ven los gerentes desde su 
perspectiva individual cobra mayor relevancia cuando éstos ascienden en la jerarquía y lle¬ 
gan al estatus de gerentes estratégicos. En esa posición pueden provocar problemas si le dan 
mayor importancia a los requerimientos de información de sus áreas funcionales que a las 
necesidades más amplias que tienen como gerentes estratégicos. 

Por ejemplo, si un gerente de producción es ascendido pero continúa dedicando mucho 
tiempo a la calendarización de la producción y al desempeño de los trabajadores, los aspec- 
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tos más amplios de la elaboración de pronósticos y políticas pueden verse afectados. Esta 
tendencia es peligrosa en toda clase de negocios: en aquellos en que los ingenieros ascienden 
poco a poco hasta la administración de empresas aeroespaciales, los profesores universita¬ 
rios que pasan de algún departamento para convertirse en decanos o los programadores que 
llegan a ejecutivos de empresas de software. Con frecuencia, su estrecha visión provoca pro¬ 
blemas al analista de sistemas que se esfuerza por separar los requerimientos de informa¬ 
ción reales de los deseos de un tipo particular de información. 



Forma en la que un gerente de marketing ve a la organización 
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PLANEACIÓN DE RECURSOS EMPRESARIALES: LA ORGANIZACIÓN COMO SISTEMA 


Un sistema de planeación de recursos empresariales [ERP, Enterprise Resource Planning) es un 
término que se emplea para describir un sistema de información organizacional (empresarial] 
integrado. El ERP es software que ayuda al flujo de información entre las áreas funcionales de 
la organización. Es un sistema personalizado que, en lugar de que se desarrolle de manera inter¬ 
na, generalmente se compra a alguna de las compañías conocidas que desarrollan software, co¬ 
mo SAP, Oracle, PeopleSoft o ID. Edwards. Después de la compra, el producto se personaliza 
para ajustarlo a los requerimientos de una compañía en particular. Es común que el fabricante 
requiera un compromiso por parte de la organización, como usuarios especializados o capaci¬ 
tación de los analistas. Muchos paquetes ERP están diseñados para ejecutarse en la Web. 

El ERP evolucionó a partir de la planeación de requerimientos de materiales (MRP, 
Materials Requirements Planning), los sistemas de información diseñados para mejorar la 
manufactura en general y el ensamble en particular. En la actualidad, los sistemas ERP in¬ 
cluyen componentes de manufactura y en consecuencia son útiles en la planeación de la ca¬ 
pacidad, la programación de la producción y la elaboración de pronósticos. Aparte de la 
manufactura (y su contraparte de servicios), el ERP incluye planeación de ventas y ope¬ 
raciones, distribución y manejo de la cadena de abastecimiento. Por lo tanto, influye signifi¬ 
cativamente en todas las áreas de la organización, como contabilidad, finanzas, administra¬ 
ción, marketing y los sistemas de información. 

La implementación de una solución ERP puede resultar desgastante porque es difícil 
analizar un sistema en uso y después ajustar el modelo ERP a dicho sistema. Además, las 
compañías por lo general diseñan sus procesos de negocios antes de implementar el ERP. 
Esta labor de rediseño se denomina reingeniería de los procesos de negocios (BRP, Business 
Process Reengineering). Lamentablemente, con frecuencia este proceso se realiza de prisa y el 
modelo de negocios propuesto no siempre coincide con la funcionalidad del ERP. Los resul¬ 
tados son personalizaciones adicionales, periodos de implementación extendidos, costos 
más altos y, con frecuencia, la pérdida de confianza del usuario. Los analistas deben tener 
presente la magnitud del problema que enfrentan al implementar paquetes ERP. 


DESCRIPCIÓN GRÁFICA "DE "SISTEMAS 

Un sistema, o subsistema, tal como existe dentro de una organización, se puede describir 
gráficamente de varias maneras. Los diversos modelos gráficos muestran las fronteras y la in¬ 
formación que se utiliza en el sistema. 

SISTEMAS Y EL DIAGRAMA DE FLUJO DE DATOS DE CONTEXTO 

El primer modelo es el diagrama de flujo de datos de contexto (también denominado mo¬ 
delo del entorno). Los diagramas de flujo se enfocan en el flujo de datos que entran y sa¬ 
len del sistema y en el procesamiento de los datos. Estos componentes básicos de cada pro¬ 
grama de cómputo se pueden describir en detalle y utilizar para analizar la precisión y 
plenitud del sistema. 

Como se muestra en la figura 2.4, el diagrama de flujo de datos de contexto sólo em¬ 
plea tres símbolos: (1) un rectángulo con esquinas redondeadas, (2) un cuadrado con dos 
bordes sombreados y (3) una flecha. Los procesos transforman los datos entrantes en infor¬ 
mación de salida, y el nivel de contenido sólo tiene un proceso, que representa el sistema 
completo. La entidad externa representa cualquier entidad que proporciona o recibe infor¬ 
mación del sistema pero que no forma parte del mismo. La entidad podría ser una persona, 
un grupo de personas, un puesto o departamento de una corporación, u otros sistemas. Las 
líneas que conectan a las entidades externas con el proceso se denominan flujos de datos, y 
representan datos. 

En la figura 2.5 se ofrece un ejemplo de diagrama de flujo de datos de contexto, que re¬ 
presenta los elementos más básicos de un sistema de reservaciones de una aerolínea. El pa¬ 
sajero (una entidad) llena una solicitud de viaje (el flujo de datos). El diagrama de contexto 
no muestra suficientes detalles para indicar con exactitud lo que sucede (ése no es su pro¬ 
pósito), pero podemos apreciar que las preferencias del pasajero y los vuelos disponibles se 
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envían al agente de viajes, quien a su vez envía información sobre la venta de boletos al pro¬ 
ceso. También podemos ver que la reservación del pasajero se envía a la aerolínea. 

En el capítulo 7 veremos que un flujo de datos contiene una cantidad considerable de 
información. Por ejemplo, la reservación del pasajero contiene el nombre de éste, la aerolí¬ 
nea, el (los) número(s) de vuelo, la (las] fecha(s) de viaje, el precio, el asiento preferido, etc. 
Sin embargo, por el momento únicamente nos interesa analizar la manera en que el diagrama 
de contexto define las fronteras del sistema. En el ejemplo anterior, tan sólo las reservacio¬ 
nes forman parte del proceso. Algunas decisiones relacionadas que podría tomar la aerolínea 
(como la compra de aviones, el cambio de programación de vuelos, la fijación de precios) no 
forman parte de este sistema. 

SISTEMAS Y EL MODELO DE ENTIDAD-RELACIÓN 

Una forma en que un analista de sistemas puede definir fronteras de sistema apropiadas es 
mediante el uso de un modelo de entidad-relación. Los elementos que conforman un sis- 
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tema organizacional se pueden denominar entidades. Una entidad podría ser una perso¬ 
na, un lugar o una cosa, como el pasajero de una aerolínea, un destino o un avión. Asimismo, 
una entidad podría ser un evento, como un fin de mes, un periodo de ventas o la descom¬ 
postura de una máquina. Una relación es la asociación que describe la interacción entre las 
entidades. 

Existen diversas convenciones para dibujar diagramas de entidad relación, o E-R (con 
nombres como notación de pata de cuervo. Flecha o Bachman). En este libro utilizamos 
la notación de pata de cuervo. Por el momento, daremos por sentado que una entidad es un 
rectángulo plano. 

La figura 2.6 muestra un diagrama de entidad-relación sencillo. Dos entidades se co¬ 
nectan mediante una línea. En este ejemplo, los extremos de la línea se marcan con dos 
líneas paralelas cortas (II), lo cual denota que esta relación es de uno a uno. De esta mane¬ 
ra, exactamente un empleado es asignado a una extensión telefónica. Nadie más comparte 
la extensión telefónica en esta oficina. 

Las flechas no forman parte del diagrama de entidad-relación. Su propósito es demos¬ 
trar cómo se debe leer el diagrama de entidad-relación. La frase del lado derecho de la línea 
se lee de la siguiente manera, de arriba hacia abajo: "Un EMPLEADO es asignado a una EX- 



Diagrama ue entidad-relación 


que muestra una relación 


muchos a uno. 
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TENSIÓN TELEFÓNICA". Del lado izquierdo, al leer de abajo hacia arriba, la flecha dice: 
"Una EXTENSIÓN TELEFÓNICA se registra a nombre de un EMPLEADO". 

De igual manera, en la figura 2.7 se muestra otra relación. La notación de pata de cuer¬ 
vo (V-t-) es evidente en este diagrama, que ilustra una relación muchos a uno. Al leer de iz¬ 
quierda a derecha, la flecha significa: "Muchos EMPLEADOS son miembros de un DEPAR¬ 
TAMENTO". Al leer de derecha a izquierda, indica: "Un DEPARTAMENTO contiene 
muchos EMPLEADOS". 

Observe que cuando se presenta una relación muchos a uno, la gramática cambia de 
"es" a "son", aun cuando el singular "es" se escribe sobre la línea. La pata de cuervo y la linea 
paralela corta no significan literalmente que este extremo de la relación debe ser un 
"muchos" obligatorio. Más bien, implica que este extremo puede ser de uno o de muchos. 

En la figura 2.8 se dan más detalles de este esquema, con varias relaciones comunes en¬ 
tre entidades. La primera, "Un EMPLEADO es asignado a una OFICINA", es una relación 
uno a uno. La segunda es una relación uno a muchos. "Un AVIÓN DE CARGA dará servicio 
a uno o más CENTROS DE DISTRIBUCIÓN". El tercero es ligeramente distinto porque 
tiene un círculo en uno de sus extremos. Se puede leer como "Un ANALISTA DE SISTE¬ 
MAS podría ser asignado a MUCHOS PROYECTOS", lo que significa que el analista podría 
ser asignado a ningún proyecto [eso es lo que significa el círculo [O], de cero], a uno o a 
muchos proyectos. De igual manera, el círculo (O) indica que en la relación próxima cabe 
la posibilidad de que no haya nada. Por lo tanto, podemos leer de la siguiente manera: "Una 
MÁQUINA podría o no recibir MANTENIMIENTO PROGRAMADO". Observe que en 
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la línea se escribe "recibe", pero las marcas al final de la línea indican que en realidad no se 
recibe mantenimiento (O) o sí se recibe mantenimiento [I], 

La siguiente relación indica: "Uno o muchos AGENTES DE VENTAS (plural de 
AGENTE DE VENTAS) son asignados a uno o muchos CLIENTEs". Es la clásica relación 
muchos a muchos. La siguiente relación se puede leer así: "La OFICINA EN CASA puede 
tener uno o muchos EMPLEADOS", o "Uno o muchos EMPLEADOS podrían ser o no 
asignados a la OFICINA EN CASA". Una vez más, la I y el O juntos implican un caso boo- 
leano, es decir, uno o cero. 

La última relación que se muestra puede leerse como: "Muchos PASAJEROS vuelan a 
muchos DESTINOs". Algunas personas prefieren utilizar el símbolo <] para denotar una 
condición "muchos" obligatoria. (¿Seria posible contar con sólo un pasajero o sólo un desti¬ 
no? } Aún así, algunas herramientas CASE como Visible Analyst no ofrecen esta posibilidad, 
aunque la condición uno o muchos opcional como se muestra en la relación AGENTE DE 
VENTAS-CLIENTE sí lo hará. 

Hasta el momento hemos modelado todas nuestras relaciones utilizando tan sólo un 
rectángulo sencillo y una línea. Este método es adecuado al examinar las relaciones de cosas 
reales como personas, lugares y objetos. No obstante, en ocasiones creamos nuevos elemen¬ 
tos en el proceso de desarrollo de un sistema de información, como facturas, recibos, archivos 
y bases de datos. Por ejemplo, cuando deseamos describir la relación entre una persona y un 
recibo es mejor indicar de una manera distinta el recibo, como se muestra en la figura 2.9 en 
forma de entidad asociativa. 

Una entidad asociativa sólo puede existir si se conecta al menos con dos entidades más. 
Por este motivo, algunos la denominan conjunción, unión, intersección o entidad concate¬ 
nada. Esta definición tiene lógica porque un recibo sólo es necesario si hay un cliente y un 
agente de ventas que realicen la transacción. 

Otro tipo de entidad es la atributiva. Cuando un analista desea mostrar datos que de¬ 
penden totalmente de la existencia de una entidad fundamental, debe utilizar una entidad 
atributiva. Por ejemplo, si una tienda de vídeos tiene muchas copias del mismo título de 
DVD, se podría utilizar una entidad atributiva para determinar cuál copia del DVD se está 
rentando. Las entidades atributivas son útiles para repetir grupos de datos que se repiten. 
Por ejemplo, suponga que vamos a modelar las relaciones que existen cuando un cliente ha¬ 
bitual compra boletos para un concierto o un espectáculo. De entrada, las entidades parecen 
evidentes: "un CLIENTE y un CONCIERTO/ESPECTÁCULO", como se observa en la 
figura 2.10. ¿Qué tipo de relación existe? A primera vista el CLIENTE obtiene una reser¬ 
vación para un CONCIERTO/ESPECTÁCULO, y se puede decir que el CONCIER¬ 
TO/ESPECTÁCULO ha realizado una reservación para un CLIENTE. 



Tres tipos distintos de entidades 
que se utilizan en diagramas E-R, 
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Entidad 


Algo útil para describir atributos, 
especialmente grupos que se 
repiten 
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Por supuesto, el proceso no es tan sencillo, y el diagrama E-R tampoco tiene que ser 
tan sencillo. En realidad, el CLIENTE obtiene una reservación, como se muestra en la figu¬ 
ra 2.11. La RESERVACIÓN es para un CONCIERTO/ESPECTÁCULO. El CONCIER¬ 
TO/ESPECTÁCULO hace la RESERVACIÓN y la RESERVACIÓN está a nombre del 
CLIENTE. Aquí agregamos una entidad asociativa porque el sistema de información re¬ 
quería una RESERVACIÓN para relacionar al CLIENTE con el CCNCIERTÓ/ESPEC- 
TÁCULC. 

De nueva cuenta este proceso es demasiado sencillo, pero dado que los conciertos y los 
espectáculos tienen muchas funciones, el diagrama de entidad-relación se dibuja una vez 
más en la figura 2.12, en la cual hemos incorporado una entidad atributiva para manejar las 
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Mejora del diagrama E-R. 
mediante: la : incorporación 
de una entidad asociativa 


denominada RESERVACIÓN. 
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Diagrama E-R más completo: 
que muestra atributos de 
daios de las entidades 



Nombre-cliente 
Dirección-cliente 
Teléfono-cliente 
T arjeta-crédito-cliente 


Número-reservación 

Nombre-cliente 

Número-función 

Concierto/Espectáculo 

Fecha 

Hora 

Localidad 

Precio 


Número-función 

Concierto/Espectáculo 

Fecha 

Hora 

Localidad 

Opciones-precio 


Concierto/Espectáculo 

Detalles-concierto 

Fechas-de-evento 

Localidad 


numerosas funciones del CONCIERTO/ESPECTÁCULO. En este caso la RESERVACIÓN 
se realiza para una FUNCIÓN específica, y la FUNCIÓN es una de las tantas que perte¬ 
necen a un CÓNCIERTÓ/ESPECTÁCULÓ. A su vez, el CÓNCIERTÓ/ESPECTÁCU- 
Ló tiene muchas funciones, y una FUNCIÓN tiene una RESERVACIÓN a nombre de un 
CLIENTE específico. 

A la derecha de este diagrama E-R se encuentra un conjunto de atributos de datos que 
conforman a cada una de las entidades, algunas de las cuales podrían tener atributos en co¬ 
mún. Los atributos subrayados se pueden buscar. Los atributos se mencionan como claves y 
se describen en el capítulo 13. 

Los diseñadores de sistemas utilizan con frecuencia los diagramas entidad-relación pa¬ 
ra modelar archivos o la base de datos. Sin embargo, es aún más importante que el analista 
de sistemas entienda en las fases iniciales las entidades y las relaciones del sistema organiza- 
cional. Para bosquejar algunos diagramas E-R básicos, el analista necesita: 

1. Enumerar las entidades de la organización para comprenderla mejor. 

2. Seleccionar entidades clave para reducir el alcance del problema a una dimensión ma¬ 
nejable y que tenga sentido. 
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3. Identificar cuál debe ser la entidad principal. 

4. Confirmar los resultados de los pasos 1 a 3 a través de otros métodos de recopilación de 
datos (investigación, entrevistas, aplicación de cuestionarios, observación y elaboración 
de prototipos), como se describe en los capítulos 4 a 6. 

Es muy importante que el analista de sistema comience a dibujar diagramas E-R tan 
pronto se incorpore a la organización en vez de esperar a que se diseñe la base de datos, por¬ 
que estos diagramas son útiles para que el analista entienda cabalmente el negocio en el que 
se desenvuelve la organización, determine el tamaño del problema y distinga si se está abor¬ 
dando el problema correcto. Es necesario confirmar o revisar los diagramas E-R conforme se 
realiza el proceso de recopilación de datos. 

Los factores organizacionales que influyen en el análisis y diseño de sistemas de infor¬ 
mación son los niveles de administración y la cultura organizacional. En las secciones res¬ 
tantes de este capítulo describiremos cada uno de estos factores y sus implicaciones para el 
análisis y diseño de sistemas de información. 


NIVELES DE ADMINISTRACIÓN 

En las organizaciones, como se muestra en la figura 2.13, la administración se divide en 
tres amplios niveles horizontales: control de operaciones, planeación y control administra¬ 
tivo (gerencia de nivel medio), y administración estratégica. Cada nivel implica sus propias 
responsabilidades y todos se enfocan, a su manera, en conseguir las metas y objetivos de la 
organización. 

El control de operaciones conforma la última capa de la administración de tres niveles. 
Los gerentes de operaciones toman decisiones aplicando reglas predeterminadas que produ¬ 
cen resultados predecibles cuando se implementan de manera adecuada. 

Estos gerentes toman decisiones que influyen en la implementación de la calendariza- 
ción del trabajo, el control de inventarios, el embarque, la recepción de materiales y el con¬ 
trol de procesos como la producción. Asimismo, supervisan los detalles de las operaciones 
de la organización. 

La gerencia de nivel medio conforma la segunda capa, o intermedia, del sistema de ad¬ 
ministración de tres niveles. Los gerentes de nivel medio toman decisiones de planeación y 
control a corto plazo respecto a cómo asignar, de la mejor manera, los recursos para cumplir 
los objetivos de la organización. 

Sus decisiones van desde la elaboración de pronósticos sobre requerimientos futuros de 
recursos hasta la solución de problemas de los empleados que pongan en peligro la produc¬ 
tividad. Se puede considerar que el dominio de toma de decisiones de los gerentes de nivel 
medio reside parcialmente en el ámbito de operaciones y parcialmente en el ámbito estra¬ 
tégico, con fluctuaciones constantes. 



En las organizaciones. Ja < , 
administración se divide en tres 
niveles horizontales: control 
de operaciones, planeación 
y control administrativo, y:... 
administración estratégica. 
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DONDE HAY CARBON, HAY UNA COPIA 


"Aún no sé qué hacemos con las copias rosas”, admitió Richard Rus- 
sell. "Son parte de un formulario cuadruplicado que se desprende por se¬ 
parado. Todo lo que sé es que las guardamos para el archivista, y que, a 
su vez, él las guarda cuando tiene tiempo". 

Richard es un ejecutivo de cuenta recién contratado por Carbón, Car¬ 
bón & Rippy, una empresa de corretaje. Usted revisa los pasos que él 
realiza para hacer ''oficial” una compra de acciones porque el jefe de Ri¬ 
chard le pidió a usted que agilizara el proceso de almacenamiento y con¬ 
sulta en computadora de la información sobre la compra de acciones. 

Cuando usted sale, Richard sigue pensando en las copias rosas, y le 
dice a su asistente, Harry Schute "En los dos meses que llevo aquf no he 
visto que alguien las utilice. Tan sólo desperdician mi tiempo y el tuyo, 
sin mencionar el espacio que ocupan. Vamos a tirarlas". 

Richard y Harry se dirigen a los viejos archivos conservados por el pre¬ 
decesor de Richard y se deshacen de todas las copias rosas archivadas, 
incluyendo las que faltaban por archivar. Esta labor les toma varias 
horas, pero consiguen liberar una cantidad considerable de espacio. "De¬ 
finitivamente valió la pena el tiempo invertido”, consuela Richard a Harry. 


Tres semanas más tarde aparece la asistente del jefe de Richard, 
Carol Vaness. Richard se alegra de ver a alguien conocido y la saluda: 
"Hola, Carol. ¿Qué te trae por aquí?" 

"Lo de siempre", suspira Carol. "Bueno, supongo que no sabes de 
qué se trata porque eres nuevo. Necesito las molestas copias rosas." 

A punto del colapso, Richard mira a Harry y balbucea: "Estás bro¬ 
meando, ¿verdad?" 

Carol mira a Richard de la manera más seria que puede y responde: 
"No bromeo. Tengo que resumir las copias rosas de todos los corredores 
y mis resultados se comparan con la Información de compra de accio¬ 
nes almacenada en la computadora. Es parte de nuestra auditoría tri¬ 
mestral de rutina para asegurar la precisión de las transacciones. Mi 
trabajo depende del de ustedes, ¿Note explicó esto el señor McCue cuan¬ 
do empezaste?" 

¿Qué concepto de sistemas ignoraron Harry y Richard cuando tiraron 
las copias rosas? ¿Cuáles son las posibles implicaciones para los ana¬ 
listas de sistemas si se ignoran los conceptos generales de sistemas? 


La administración estratégica es el tercer nivel del control de administración de tres ni¬ 
veles. Los gerentes estratégicos voltean hacia fuera de la organización para visualizar el fu¬ 
turo, tomando decisiones que conducirán a los gerentes de nivel medio y de operaciones en 
los meses y años venideros. 

Los gerentes estratégicos se desenvuelven en un entorno de toma de decisiones suma¬ 
mente incierto. Mediante la formulación de metas y el establecimiento de estrategias y 
políticas para alcanzar tales metas, los gerentes estratégicos son quienes en realidad definen 
a la organización como un todo, La compañía se apoya en la amplia visión de estos gerentes 
para decidir el desarrollo de nuevas líneas de productos, desprenderse de negocios poco re¬ 
dituables, adquirir otras compañías afines o incluso permitir su propia venta. 

Existen contrastes bien definidos en diversos aspectos entre los encargados de la toma 
de decisiones. Por ejemplo, los gerentes estratégicos tienen que tomar decisiones sobre una 
gran cantidad de objetivos, en tanto que los gerentes de operaciones se enfocan en uno solo. 
A los gerentes de alto nivel se les dificulta identificar problemas, pero los gerentes de ope¬ 
raciones los detectan con facilidad. Los gerentes estratégicos se enfrentan a problemas 
semiestructurados, mientras que los gerentes de nivel medio lidian en su mayor parte con 
problemas estructurados. 

Por lo general, es difícil articular las soluciones alternativas a un problema que enfren¬ 
tan los gerentes estratégicos, pero comúnmente es fácil enumerar las alternativas con las 
que trabajan los gerentes de operaciones. Con frecuencia, los gerentes estratégicos toman 
decisiones que se aplican sólo una vez, en tanto que los gerentes de operaciones toman de¬ 
cisiones que se aplican de manera repetitiva. 


IMPLICACIONES PARA DEL DESARROLLO DE SISTEMAS DE INFORMACION 

Cada uno de los tres niveles de administración representa implicaciones distintas para el de¬ 
sarrollo de sistemas de información. Algunos de los requerimientos de información de los 
gerentes están bien definidos, en tanto que otros son confusos y se traslapan. 

Los gerentes de operaciones necesitan información interna de naturaleza repetitiva y 
de bajo nivel. Dependen principalmente de información que muestra el desempeño actual, 
y son usuarios de recursos de información en línea y en tiempo real. Tienen una necesidad 
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"Realmente lo estábamos buscando", dice Paul LeGori. En su calidad ting con el propósito de que pudiéramos compartir en toda la organiza- 
de analista de sistemas, le han hecho a usted una Invitación para co- dón las cifras sobre inventarios y ventas recién incorporadas a los siste- 

laborar en Pyramid, Inc., una pequeña empresa editorade libroS;inde A mas de cómputo. Argumentaron que estos comités podrían eliminar la 

pendiente, que se especializa en libros con cubierta rústica sobre temas duplicación innecesaria de información y que cada área funcional se in- 
P 0 C 0 Convencionales.;’. : *: -• : ; tegraría mejor con todas las demás". 

Paul continúa: "Aquípublicamos temas que algunos consideran in- , : , Paul abundó: "Esto funcionó—aunque por un tiempo—y los em- 

sólitos. Ya sabes, eípodende la pirámide, 1 profecías sobre el fin del mundo ¡pleados compartieron información, pero la razón por la que lo ñecésita-r 

y vivir de manera más saludable pensandoen el color rosa. Cuando la ; : mos-a-usted es que los empleados dicen que.no tienen tiempo para las: 
gente ve nuestros libros, sacuden la cabeza y dicen: 'Uff, temas rara?', * ¡ reuniones dé los comités y no les agradó compartir información con 
Pero no estamos sujetos a una filosofía en especial y hemos tenido mu- miembros de otros departamentos que se encuentran más arriba que 

cho éxito. A tal grado, qué como tengo 24 años me¡ dicen 'eljoven rey'". . ellos en la jerarquía de la organización". 

Paul hace una pausa para ver la reacción de usted, ’y. . De acuerdo con; Pauí y Cell, ¿cuáles fueron los efectos de haber 

Pauicontinúa: "Yo soy él presidente, y mé' hago cargo de áreas fun- instalado en Pyramid, Inc., un sistema de información gerencia! que 
dónales como editorial; contabilidad, producción y marketing". : ”J obligaba a la gente a compartir información de una manera que no 
La secretaria de Paul, CélIToom, quien hasta ahora había estado es- coincidía con su estructura jerárquica? Sugiera algunas alternativas 
cuchando tranquilamente, interviene abruptamente: "Los últimos exper- generales para solucionar este problema de tal forma que permita a los 

tos en sistemas que han trabajado con nosotros nos recomendaron la empleados de Pyramid conseguir las cifras de ventas e inventario que 

formación de comités de enlace entre contabilidad, producción y marké 1 :: requieren. ■ A ■ v ::V ■ ’ 
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moderada de información periódica y sobre el desempeño pasado. Rara vez utilizan informa¬ 
ción externa para realizar proyecciones a futuro. 

En el siguiente nivel de administración, los gerentes de nivel medio requieren informa¬ 
ción tanto de corto como de largo plazo. Dada la naturaleza relacionada con la resolución 
de problemas de sus trabajos, los gerentes de nivel medio tienen necesidades extremadamen¬ 
te altas de información en tiempo real. Para realizar un control adecuado, también requie¬ 
ren información actual sobre el desempeño medido contra los estándares establecidos. Los 
gerentes de nivel medio dependen considerablemente de la información interna. A diferen¬ 
cia de los gerentes de operaciones, tienen una alta necesidad de información histórica, al 
igual que de información que les permita pronosticar eventos futuros y simular numerosos 
escenarios posibles. 

Los requerimientos de información de los gerentes estratégicos difieren en cierta medida 
de los requerimientos que tienen tanto los gerentes de nivel medio como los de operacio¬ 
nes. Dependen de información proveniente de fuentes externas que proporcionan noticias 
sobre las tendencias del mercado y las estrategias de la competencia. Dado que las tareas de 
la administración estratégica están relacionadas con la proyección de un futuro incierto, los 
gerentes estratégicos tienen una considerable necesidad de información de naturaleza pre- 
dictiva y de información que les permita generar una gran cantidad de escenarios del tipo 
"qué pasaría si". Los gerentes estratégicos también presentan fuertes necesidades de infor¬ 
mación periódica con el propósito de adaptarse a la velocidad de los cambios. 


CULTURA ORGANIZACIONAL 

La cultura organizacional es un área de investigación que ha crecido de manera notable en la 
última generación. Así como es correcto considerar que las organizaciones dan cabida a mu¬ 
chas tecnologías, también es conveniente considerarlas como receptáculos de múltiples sub¬ 
culturas, que con frecuencia compiten entre sí. 

Aún no hay un consenso sobre la definición precisa de lo que constituye una subcultu¬ 
ra organizacional. Sin embargo, sí hay consenso en que las subculturas podrían entrar en 
conflictos y competir para ganar adeptos a su visión de lo que debería ser la organización. 
Actualmente se realizan estudios para determinar los efectos de las organizaciones virtuales 
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y los equipos virtuales en la creación de subculturas cuando los miembros no comparten un 
espacio de trabajo físico pero sí comparten tareas. 

En lugar de ver a la cultura como un todo, es más útil considerar los factores determi¬ 
nantes de las subculturas, como los simbolismos verbales y no verbales compartidos. Los 
simbolismos verbales incluyen el lenguaje compartido para construir, transmitir y preservar 
los mitos, metáforas, visiones y estados de ánimo de las subculturas. Los simbolismos no ver¬ 
bales incluyen objetos, ritos y ceremonias compartidos; la vestimenta de los encargados de 
la toma de decisiones y de los trabajadores; el uso, ubicación y decoración de las oficinas, 
y la forma de celebrar los cumpleaños, promociones y jubilaciones de los miembros. 

Las subculturas coexisten dentro de las culturas "oficiales" de la organización. La cultura 
oficial aprobada podría establecer una forma de vestir, formas apropiadas de dirigirse a los 
superiores y a los compañeros, así como la manera más conveniente de tratar al público. 
Las subculturas se podrían constituir en factores determinantes de los requerimientos, dis¬ 
ponibilidad y uso de la información. 

Los miembros de la organización podrían pertenecer a una o más subculturas. Estas úl¬ 
timas podrían ejercer una fuerte influencia en el comportamiento de los miembros, inclu¬ 
yendo castigos por o contra el uso de los sistemas de información. 

La comprensión e identificación de las subculturas que predominan en una organiza¬ 
ción podría ayudar al analista de sistemas a superar la resistencia al cambio que surge al ins¬ 
talar un nuevo sistema de información. Por ejemplo, el analista podría planear la capacitación 
de usuarios para resolver problemas específicos de las subculturas de la organización. La 
identificación de las subculturas también podría ser útil para diseñar sistemas de apoyo a 
la toma de decisiones adecuados para interactuar con grupos específicos de usuarios. 



RESUMEN 

Existen tres aspectos fundamentales de la organización que se deben tomar en cuenta al 
analizar y diseñar sistemas de información: el concepto de organizaciones como sistemas, 
los diversos niveles de administración y la cultura general de la organización. 

Las organizaciones son sistemas complejos compuestos de subsistemas interrelaciona¬ 
dos e interdependientes. Además, los sistemas y subsistemas se caracterizan por sus entor¬ 
nos internos que van de un continuo abierto a cerrado. Un sistema abierto permite el libre 
tránsito de recursos (gente, información, materiales) a través de sus fronteras; los sistemas 
cerrados no permiten el libre flujo de entrada o salida. Las organizaciones y los equipos 
también se pueden organizar virtualmente mediante la conexión electrónica de sus miem¬ 
bros remotos ubicados en diferentes espacios de trabajo físicos. Los sistemas de planeación 
de recursos empresariales son sistemas de información organizacional (empresarial) inte¬ 
grados, desarrollados mediante software comercial personalizado, que ayudan al flujo de 
información entre las áreas funcionales de la organización. Permiten obtener una vista de los 
sistemas de la organización. 

Los diagramas de entidad-relación ayudan al analista de sistemas a comprender las en¬ 
tidades y relaciones que conforman el sistema organizacional. Los diagramas E-R pueden 
describir relaciones uno a uno, uno a muchos, muchos a uno y muchos a muchos. 

Los tres niveles de control administrativo son el operativo, el de nivel medio y el estra¬ 
tégico. El horizonte de tiempo para la toma de decisiones es diferente en cada nivel. 

Las culturas y subculturas de una organización son factores importantes que determi¬ 
nan la manera como la gente utiliza la información y los sistemas de información. Al con¬ 
siderar a los sistemas de información en el contexto de la organización como un sistema 
más grande, entenderemos que hay diversos factores importantes que debemos tomar en 
cuenta al determinar los requerimientos de información y diseñar e implementar sistemas 
de información. 
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"Al parecer ha empezado bien su experiencia con MRE. Aun cuando yo le puedo informar 
muchas cosas en relación con la compañía, recuerde que tiene diversas opciones para orien¬ 
tarse por sí mismo dentro de ella. Tendrá que: entrevistar usuarios, analizar sus patrones de 
toma de decisiones y revisar informes, gráficas y diagramas archivados. Para ello, podrá se¬ 
leccionar el directorio telefónico para conseguir una cita con. una persona para realizar una 
entrevista, elegir el mapa del edificio para observar la disposición de las instalaciones o 
seleccionar los organigramas para conocer las áreas funcionales y las jerarquías formales 
existentes en MRE." ~ ; v • ; •••' :• ■; ; 

"Muchas de las reglas de la vida corporativa son válidas también para él HyperCase dé 
MRE. Por ejemplo, hay muchas áreas públicas por las cuales puede Usted transitar libre¬ 
mente. Sin embargo, si desea visitar una oficina corporativa privada A primerodebe concertar 
una cita con uno de nuestros empleados. Algunas áreas seguras están estrictamente fuera 
dé su alcance, porque usted no pertenece a la organización y podría representar riesgos dé 
seguridad:" : - : • 7 : ' • 

"Sin embargo, no creo que usted nos considere demasiado recelosos A porqué puede dar 
por sentado qué cualquier empleado que le conceda una entrevista le dará acceso al mate¬ 
rial archivado lo mismo que a su trabájo actual En la mayoría dé los casos, podrá realizar 
libremente su laboir de consultaría, Si usted fuera demasiado inquisitivo o invadiera nues¬ 
tra privacidad/se lo diríamos de inmediato. Ño tenemos problemas para decirle cuáles son 
los límites." .;• • V 

"No obstante, algunos miembros de la compañía parecen nunca tenertiempp para los 
consultores. Si necesita más datos sobre estas personas/difícilesde entrevistar^ le: sugiero que; 
persevere. Hay muchas maneras para averiguar lo que se necesita acerca de los miembros y 
los sistemas de MRE, pero muchas veces lo que da mejor resultado es la creatividad. Se da¬ 
rá cuenta de que los mejores consultores de sistemas en MRE son aquellos que se guían por 
su intuición, afinan sus habilidades y nunca dejan de pensar en maneras de reunir las piezas 
de información disponible." 7 : 



Seleccione palabras clave en HyperCase para averiguar más detalles. 
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"Recuerde que debe utilizar métodos diversos —entrevistas, observación e investiga¬ 
ción- - * P ara comprender lo que pretendemos decirle en MRE. ¡En ocasiones, las acciones, 
documentos y oficinas dicen más que las palabras!" 


PREGUNTAS DE'HYPERCASE 

1. ¿Qué cambio organizacional importante tuvo lugar recientemente en MRE? ¿Qué de- 
partamentofs] se vieron involucrados y por qué se realizó el cambio? 

2. ¿Qué hace la Unidad de Sistemas de Administración [Management Systems Unit) de 
MRE? ¿Quiénes son sus clientes? 

3. ¿Cuáles son las metas y estrategias de la División de Ingeniería y Sistemas /Engineering 
and Systems División) de MRE? ¿Cuáles son las metas del Departamento de Capacita¬ 
ción y Administración de Sistemas [Training and Management Systems Department)? 

4. ¿Calificaría usted a MRE como una industria de servicios, manufacturera o ambas? 
¿Qué tipo de "productos" "produce" MRE (es decir, ofrece bienes muebles, servicios o 
ambos)? Describa de qué manera el tipo de industria en el que se desenvuelve MRE in¬ 
fluye en los sistemas de información que utiliza. 

5. ¿Qué tipo de estructura organizacional tiene MRE? ¿Cuáles son las implicaciones de 
esta estructura para el área de sistemas? 

6. Describa en un párrafo las "políticas" del Departamento de Capacitación y Administra¬ 
ción de Sistemas de MRE. ¿Quiénes son los involucrados y cuáles son algunos de los as¬ 
pectos principales? 


PALABRAS Y FRASES CLAVE 

administración de operaciones 
administración estratégica 
apertura 
cerrazón 

cultura organizacional 
diagramas de relación-entidad (E-R) 
empresa virtual 

entidad (entidad fundamental) 
entidad asociativa 
entidad atributiva 
entorno 


equipo virtual 
fronteras organizacionales 
gerencia de nivel medio 
interdependiente 
interrelación 

notación de pata de cuervo 
organización virtual 
planeación de recursos empresariales 
(ERP) 

retroalimentación 

sistemas 


PREGUNTAS DE REPASO 

1. ¿Cuáles son los tres grupos de aspectos fundamentales de una organización que influ¬ 
yen en el desarrollo de sistemas de información? 

2. ¿Qué significa decir que los subsistemas organizacionales se interrelacionan y son inter¬ 
dependientes? 

3. Defina el término frontera organizacional. 

4. ¿Cuáles son los dos propósitos principales de la retroalimentación en las organizaciones? 

5. Defina el concepto de apertura en el entorno de una organización. 

6. Defina el concepto de cerrazón en el entorno de una organización. 

7. ¿Cuál es la diferencia entre una organización tradicional y una virtual? 

8. ¿Cuáles son los beneficios potenciales y una desventaja de una organización virtual? 
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9. Dé un ejemplo de una situación en la cual los analistas de sistemas trabajen con los 
usuarios como un equipo virtual. 

10. ¿Qué es ERP y cuál es su propósito? 

11. ¿Qué problemas enfrentan con frecuencia los analistas al implementar un paquete 
ERP? 

12. ¿Qué significa el concepto diagrama de entidad-relación? 

13. ¿Qué símbolos se utilizan para elaborar diagramas E-R? 

14. Mencione los tipos de diagramas E-R. 

15. ¿En qué difieren una entidad, una entidad asociativa y una entidad atributiva? 

16. Mencione los tres niveles principales de administración horizontal de las organizaciones. 

17. ¿Cómo puede ayudar la comprensión de las subculturas organizacionales al diseñar sis¬ 
temas de información? 


PROBLEMAS 

1. "Es difícil enfocarnos en los objetivos que intentamos alcanzar. Observo lo que hacen 
nuestros competidores reales, los minisuper (tiendas de conveniencia), y creo que de¬ 
bemos hacer lo mismo. Después atiendo a un centenar de clientes y cada uno me dice 
que continúe igual con mi pequeña tienda, con dependientes amables y cajas registra¬ 
doras antiguas. Más tarde, en la revista SuperMarket News me entero de que la ola del 
futuro son las supertiendas de abarrotes, en donde los precios no se marcan uno por 
uno y los lectores de códigos de barras sustituyen a los dependientes. Son tantas las ten¬ 
dencias que en realidad no soy capaz de establecer una estrategia para nuestra tienda de 
abarrotes", acepta Geoff Walsham, propietario y administrador de la tienda de abarro¬ 
tes Jiffy Geoffs. 

En un párrafo, aplique el concepto de fronteras organizacionales permeables para 
analizar el problema de Geoff al enfocarse en los objetivos organizacionales. 

2. Explique en siete oraciones las relaciones de derecha a izquierda de la figura 2.8. 

3. Dibuje un diagrama de entidad-relación para una relación paciente-médico. 

a. ¿De cuál de los tipos de diagrama E-R se trata? 

b. Explique en una o dos oraciones por qué se diagramó de esta manera la relación 
paciente-médico. 

4. Usted empieza a dibujar diagramas E-R tan pronto como ingresa a la organización de¬ 
dicada al cuidado de la salud para la cual diseña un sistema. Los miembros de su equi¬ 
po muestran reticencia al uso de diagramas E-R antes de empezar el diseño de la base 
de datos. En un párrafo, convenza a los miembros de su equipo de que vale la pena el 
uso temprano de diagramas E-R. 

5. Sandy es gerente de la compañía de alimento para perros Arf-Arf. Dado que existen di¬ 
versos proveedores de ingredientes y sus precios varían, Sandy ha elaborado diferentes 
fórmulas para el mismo producto, que dependen de la disponibilidad de ingredientes de 
alguno de los proveedores. Realiza sus pedidos según esta disponibilidad y lo hace de ma¬ 
nera rutinaria, aunque desconozca los precios de los ingredientes en un momento dado. 

a. ¿En qué nivel de administración se desenvuelve Sandy? Explíquelo en un párrafo. 

b. ¿Qué atributos de su trabajo tendrían que cambiar para que usted la considere en 
un nivel de administración diferente? Menciónelos. 

6. Muchos de los miembros de la compañía de alimento para perros Arf-Arf se mofan del 
nombre de la compañía y de lo absurdo que es el que una compañía que elabora ali¬ 
mento para perros sea tan importante. Sin embargo, otros grupos de la compañía están 
orgullosos de los productos de Arf-Arf y de su reputación de elaborar productos de ca¬ 
lidad, y ostentan felices los premios que han recibido de la industria. Mencione en un 
párrafo los nombres de las subculturas organizacionales que se aprecian en Arf-Arf 


PROYECTOS DE GRUPO 

1. Formen grupos de cinco alumnos. Designen a uno como diseñador del sitio Web, uno 
como redactor de la publicidad de un producto, uno que se encargue de los pagos de 
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los clientes, uno para la distribución y uno para atender a los clientes que tengan dudas 
sobre el uso del producto. A continuación elijan un producto sencillo (alguno que no 
tenga demasiadas versiones distintas). Podría ser una cámara desechable, un reproduc¬ 
tor de DVD, una caja de dulces o un sombrero para viajar. Inviertan 20 minutos para 
explicar al diseñador del sitio Web lo que colocará en el sitio. Describa en aproximada¬ 
mente tres párrafos la experiencia que tuvo su grupo en la coordinación. Dé más deta¬ 
lles sobre la interrelación de subsistemas en la organización (su grupo). 

2. En grupo, dibujen un diagrama de flujo de datos de contexto del sistema de registro o 
inscripción de su colegio o universidad. Rotulen cada entidad y proceso. Expliquen por 
qué hay, al parecer, diferentes maneras de dibujar el diagrama. Decidan en grupo cuál 
es la mejor manera de dibujar el diagrama y, en un párrafo, defiendan su postura. Ahora, 
en conjunto con los miembros de su grupo, sigan los pasos apropiados para desarrollar 
un diagrama E-R y generen uno para el sistema de registro de su colegio o universidad. 
Asegúrese de que su grupo determine si la relación que usted muestra es uno a uno, 
uno a muchos, muchos a uno o muchos a muchos. 


BIBLIOGRAFÍA SELECCIONADA 

Bleeker, S. E., "The Virtual Organization", Futurist, vol. 28, núm. 2, 1994, pp. 9-14. 

Chen, R, "The Entity-Relationship Model-Towards a Unified View of Data", ACM Tran- 
sactions on Datábase Systems, vol. 1, marzo de 1976, pp. 9-36. 

Ching, C, C. W. Holsapple y A. B. Whinston, "Toward IT Support for Coordination 
in NetWork Organizations", Information Management, vol. 30, núm. 4, 1996, 
pp. 179-199. 

Davis, G. B. y M. H. OI son, Management Information Systems, Conceptual Foundations, 
Structurey Development, 2a. ed., Nueva York: McGraw-Hill, 1985. 

Galbraith, J. R., Organizational Design. Reaáing, MA: Addison-Wesley, 1977. 

Rendan, K. E., J. R. Buffmgton y J. E. Kendall, "The Relationship of Organizational 

Subcultures to DSS User Satisfaction", Human Systems Management, marzo de 1987, 
pp. 31-39. 

PeopleSoft. Disponible en: (www.peoplesoft.com/corplen/publicjndex.jspl). Última visita 
el 3 de junio de 2003. 

Warkentin, M., L. Sayeed y R. Hightower, "Virtual Teams versus Face-to-Face Teams; An 
Exploratory Study ofaWeb-Based Conference System", en EmergingInformation 
Technologies: Improving Decisions, Cooperationy Infrastructure, editado por K. E. 
Kendall, pp. 241-262. Thousand Oaks, CA: Sage Publications, 1999. 

Yager, S. E. "Everything's Corning Up Virtual." Disponible: (www.acm.org/crossroads/ 
xrds4-l/organi.html). Última visita el 3 de junio de 2003. 


FUNDAMENTOS DEL ANALISIS DE SISTEMAS 





ALLEN SCHMIDT, JULIE E. KENDALLY KENNETH E. KENDALL 



DESCRIPCIÓN DE LAS RELACIONES 



'Así que el proyecto involucra más que simplemente darle mantenimiento a los programas 
actuales", dice Chip. "¿Vamos a utilizar una metodología formal para analizar y diseñar el 
nuevo sistema?" 

"Sí", contesta Anna. "También vamos a utilizar una herramienta CASE, Visible Analyst, 
para analizar y diseñar el sistema. 1 Hace poco instalamos el producto en la PC de la oficina." 

Con unos cuantos clics del ratón Anna abre un diagrama de flujo de datos de contexto 
(véase la figura E2.1}. "Para empezar, es muy útil considerar al sistema de esta forma", dice 
Anna mientras observan el diagrama en la pantalla. 

Chip coincide: "Puedo ver fácilmente lo que crees que está ocurriendo en el sistema. 
Por ejemplo, veo que la entidad externa Administración plantea dudas sobre el hardware y 
el software y recibe las respuestas correspondientes. De esta forma el sistema se aprecia en el 
contexto más amplio de la organización". 



r '""" AlEiJ 


Diagrama de flujo de datos de contexto, sistema actual. 



'Para más detalles sobre cómo utilizar Visible Analyst, véase Alien Schmidt, Working with Visible Analyst, 2a. 
edición (UpperSaddle River, NJ: Prentice Hall, 2004). 

El caso de la Central Pacific University se puede adaptar a otras herramientas CASE, como Microsoft Visio. 
Asimismo, muchos de los ejercicios se pueden realizar manualmente si no se dispone de herramientas CASE. 
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Diagrama entidad-relación, sistema actual. 


"También hice un diagrama E-R del sistema", dice Anna al tiempo que muestra el dia¬ 
grama entidad-relación en la pantalla (véase la figura E2.2). 

"Sí, las relaciones muchos-a-muchos y uno-a-muchos son muy claras cuando las ves 
así", comenta Chip al ver la pantalla. "Has tenido un buen comienzo", continúa Chip. "Pon¬ 
gámonos a trabajar y veamos qué necesitamos hacer a continuación." 


EJERCICIOS 



E-l. Utilice Visible Analyst par ver e imprimir el diagrama de flujo de datos de contexto 
del sistema de inventario por computadora, como hicieron Chip y Anna. 

E-2. Utilice la característica Repository para ver la entrada del proceso central. 

E-3. Utilice Visible Analyst para ver e imprimir el diagrama de entidad-relación del siste¬ 
ma de inventario por computadora. 

E-4. Explique por qué las entidades externas en el diagrama de contexto no se encuentran 
en el diagrama de entidad-relación. 

E-5. Explique por qué las entidades ADMINISTRACIÓN y PROFESORADO se encuen¬ 
tran en ambos lados del proceso en el diagrama de contexto. 


Los ejercicios precedidos por un ¡cono Web indican que hay matenal adicional en el sitio Web del libro. Los 
estudiantes pueden descargar un proyecto de muestra de Visible Analyst y una base de datos de Micro¬ 
soft Access para realizar los ejercicios. 
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DETERMINACIÓN DE LA 
VIABILIDAD Y ADMINISTRACIÓN 
DE LAS ACTIVIDADES DE 
ANÁLISIS Y DISEÑO 


' llfllÉ ¡1 WMüp^PMSL 

OBJETIVOS DE APRÍENQÍZAÍ?; 

Una vez que haya dominado el material de este capítulo, podrá: 

1. Comprender cómo se inician y seleccionan los proyectos,- 

2. Determinar la viabilidad de un proyecto propuesto. 

3. Planear un proyecto identificando actividades y programándolas. 

4. Entender la manera en que un enfoque alterno denominado programación extrema equilibra 
los objetivos para administrar el proceso de análisis y diseño. 

5. Administrar las actividades de análisis y diseño de tal manera que se cumplan los objetivos 

dentro de! plazo destinado al proyecto. ;. 


Entre las capacidades fundamentales que debe dominar un analista de sistemas se incluyen 
la iniciación de proyectos, la determinación de la viabilidad de ún proyéctó, la programación 
de proyectos, y la planeación y administración de las actividades y los miembros de un equi¬ 
po para optimizar la productividad. Estas capacidades se consideran aspectos fundamenta¬ 
les de un proyecto. í-LE-T' .• ' - - • : 

Un proyecto de sistemas comienza con problemas o con oportunidades de realizar me¬ 
joras en un negocio, que surgen con frecuencia conforme la organización se adapta al-cam¬ 
bio. La creciente popularidad del comercio electrónico pone de.manifiesto que algunos 
cambios importantes se están generando a medida que los negocios inician sus empresas en 
Internet o cuando trasladan sus operaciones internas y sus relaciones externas a esté medio' 
de comunicación. Los cambios qué requieren uria soluciónale sistemas pueden surgir del 
entorno legal asi corno del medio ambiente donde opera la empresa. Una Vez que se propone 
un proyectó; el analista de sistemas trabaja rápidamente en colaboración con los encargados 
de la toma de decisiones para determinar la viabilidad del misino. Si. se aprueba un provéete).; 
para un estudio de sistemas completo, las actividades del proyecto se programan con.ayuda 
de herramientas como gráficas de Gantt y diagramas de Técnicas de Evaluación \ Revisión de. 
Programas (PERT, Progrintí Evaluátmnand Rcvww Techniques I a fin de terminar a tiempo el 
proyecto. Para asegurar la productividad de los miembros del equipo de análisis de sistemas 
es fundamental la.administración eficaz de sus actividades programadas. Este capítulo se dé-; 
dica a examinar estos aspectos esenciales de los proyectos • 


INICIACION DE UN PROYECTO . 

Son muchas y distintas las fuentes que dan inicio a los proyectos de sistemas, por diversas, 
razones. Algunos dei los proyectos sugeridos sobrevivirán varias etapas de evaluación hasta 


























llegar a usted (o a usted y su equipo); otros no conseguirán llegar tan lejos. Los ejecutivos de 
negocios sugieren proyectos de sistemas por dos razones principales: (1) porque tienen pro¬ 
blemas que requieren una solución de sistemas, y (2) porque identifican oportunidades de 
mejorar mediante la actualización, modificación o instalación de nuevos sistemas cuando 
ocurren problemas. Ambas situaciones se pueden dar conforme las organizaciones se adap¬ 
tan y enfrentan al cambio evolutivo y natural. 


PROBLEMAS EN LA ORGANIZACIÓN 

A los administradores no les agrada aceptar que sus organizaciones tienen problemas, y mu¬ 
chos menos hablar de ellos con alguien externo. No obstante, los buenos administradores 
están conscientes de que para mantener el negocio funcionando a su más alto potencial es 
imperativo que reconozcan los síntomas de los problemas o, en etapas más avanzadas, que 
los diagnostiquen y les hagan frente. 

Los problemas surgen de diversas maneras. Una forma de averiguar que hay problemas 
y cómo se originaron, es considerarlos como situaciones en las cuales ya no se alcanzan o 
nunca se han alcanzado las metas fijadas. La retroalimentación útil pone de manifiesto la 
brecha existente entre el desempeño real y el que se pretende. De esta manera, la retroali¬ 
mentación ayuda a resaltar los problemas. 

En algunos casos, los problemas que requieren la atención del analista de sistemas per¬ 
manecen ocultos porque no se realizan mediciones del desempeño. Los problemas (o sín¬ 
tomas de problemas) en procesos cuyos resultados son visibles y que podrían requerir la 
ayuda de un analista de sistemas incluyen errores excesivos y trabajo realizado con dema¬ 
siada lentitud, incompleto, incorrecto o que no se hace. Otros síntomas de problemas se 
vuelven evidentes cuando los individuos no cumplen las metas de desempeño establecidas. 
Los cambios en el comportamiento de los empleados como una elevada tasa de ausentis¬ 
mo, creciente descontento en el trabajo o una alta rotación de trabajadores deben alertar a 
los administradores sobre la existencia de problemas potenciales. Cualquiera de estos cam¬ 
bios, solos o en combinación, constituyen una razón de peso para solicitar la ayuda de un 
analista de sistemas. 

Aunque los problemas como los recién descritos ocurren al interior de las organizacio¬ 
nes, la retroalimentación sobre qué tan bien cumple la organización sus metas podría llegar 
del exterior, en forma de quejas o sugerencias por parte de clientes, distribuidores o provee¬ 
dores, y pérdida o reducción inesperada de ventas. Esta retroalimentación del entorno ex¬ 
terno es sumamente importante y no debe ignorarse. 

En la figura 3.1 se ofrece un resumen de síntomas de problemas y de técnicas útiles pa¬ 
ra la detección de los mismos. Advierta que la revisión de resultados, la observación del 
comportamiento de los empleados y la atención a la retroalimentación proveniente de 



La revisión de resultados, la 
observación del comportamiento 
de los empleados y la atención 
a la retroalimentación son 
factores que ayudan al analista 
a identificar problemas y 
oportunidades de sistemas. 


Para Identificar problemas 


Busque estos signos específicos 


Revise los resultados contra los criterios 
" de desempeño 


Observe el comportamiento de los empleados 


Demasiados errores 
Trabajo, realizado con lentitud 
Trabajo realizado de manera Incorrecta 
Trabajo incompleto 
Trabajo no realizado 


s Elevado ausentismo 

• Creciente descontento 

• Alta rotación de trabajadores 


Ponga atención en la retroalimentación externa de 
Distribu dores 
• Clientes: 

Proveedores 


Quejas.. -L; 
Sugerencias de mejora 
Pérdida de ventas 
Reducción de ventas 
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EL SONIDO MAS DULCE QUE HE PROBADO 


Félix Straw, uno de los muchos distribuidores en Estados Unidos de 
la bebida europea Sipps, mira tristemente el mapa climático de un dia¬ 
rio saturado de áreas rojas, las cuales indican que la mayor parte del 
territorio de Estados Unidos sufre una onda calurosa que no muestra 
signos de aminorar. Señalando el periódico conformé habla, le indica a 
los miembros de su grupo de sistemas: "Esto es lo mejor que nos pudo 
pasar, o al menos debería serlo. ¡Pero cuando hicimos nuestros pedidos : 
hace tres meses, no teníamos la menor idea de que esta monstruosa 
onda de calor iba a devorar así al país!" Volteando hacia una fotografía 
de su planta europea que se encuentra sobre la pared, continúa: "Debe¬ 
mos encontrar la manera de informarles cuando el clima esté caluroso 
por acá para que nos envíen suficiente producto. De lo contrario, siem¬ 
pre perderemos las oportunidades. Esto ocurrió hace dos anos y casi 


n o s mata. 


"Cada uno de los distribuidores nos reunimos con nuestros gerentes 
de distrito para realizarla planeación trimestral. Cuando llegamos a un 
acuerdo, enviamos nuestros pedidos por fax a las oficinas centrales en 
Europa. Ellos hacen sus propios ajustes, envasan las bebidas y nos 
mandan los pedidos modificados de 9 a 15 semanas después. Pero ne¬ 
cesitamos encontrar la manera de indicarles lo que está ocurriendo ahora, 
¡Vaya!, incluso se están abriendo nuevos centros comerciales aquí. Ellos 
deberían saber que tenemos una demanda extraordinariamente alta". 

Corky, su secretaria, estuvo de acuerdo: "Sí, aLmenos deberían 
echarle un vistazo a nuestras ventas anteriores en esta época del año. 
Algunas primaveras son calurosas y otras son normales". 

Straw coincidió: "Eso sería música para mis oídos, sería realmente 
grandioso que ellos trabajaran de manera conjunta con nosotros para 


identificar las tendencias y los cambios —y a continuación responder 
con rapidez", 

Stern's, fabricante de bebidas cuyas oficinas centrales se encuentran 
en Blackpool, Inglaterra, es el productor de Sipps. Ésta es una bebida dul¬ 
ce, no carbonatada, sin alcohol, con sabor a frutas, que se toma fría o con 
hielo y tiene una ; alta demanda en época de calor. Con buenas ventas en 
Europa y una creciente popularidad en Estados Unidos desde su introduc¬ 
ción hace cinco años, Sipps ha experimentado dificultades para manejar 
de manera adecuada el inventario y satisfacer la demanda de los clientes 
estadounidenses, 1 que se ve afectada por las fluctuaciones de temperatu¬ 
ra de cada estación. Los lugares con climas cálidos durante todo el año y 
cantidades considerables de turistas (como Florida y California) realizan 
pedidos voluminosos de; manera habitual, pero otras áreas de Estados 
. Unidos; podrían beneficiarse con un proceso de toma de pedidos menos 
engorroso y mayor capacidad de respuesta. La bebida es comercializada 
por una red de distribuidores locales portodo Estados Unidos y Canadá. 

Como uno de los analistas de sistemas asignado a trabajar con los 
distribuidores estadounidenses de Sipps, Inicie su análisis enumerando 
algunos de los síntomas y problemas clave que haya identificado luego 
de entrevistar al señor Straw y a su secretaria, estudiar los flujos de in¬ 
formación, el proceso de toma de pedidos y la administración de inven¬ 
tarios. Describa en un párrafo los problemas que podrían indicar la ne¬ 
cesidad de una solución de sistemas. 


Nota: Esta oportunidad de consultaría se elaboró con base en J. C. Pérez, "Helneken’s 
HOPS Software Keeps A-Head on Inventory", PC Week, vol. 14, núm. 2,13 de enero de 
. 1 997.pp.31 y34. ; 


fuentes externas son valiosas para la detección de problemas. Como se discutió en el capí¬ 
tulo 1, al responder a los problemas que se presentan en una organización, el analista de sis¬ 
temas desempeña los roles de consultor, experto en soporte técnico y agente de cambio. 
Como cabría esperar, los roles del analista de sistemas cambian sutilmente cuando se inician 
los proyectos, porque la atención se concentra en las oportunidades de mejora más que en la 
necesidad de solucionar problemas. 


SELECCIÓN DE PROYECTOS 

Los proyectos surgen de diferentes fuentes y por muchas razones. No todos deben seleccio¬ 
narse para un estudio más profundo. Usted debe tener bien presentes las razones para reco¬ 
mendar el estudio de sistemas de un proyecto que parezca resolver un problema o propiciar 
una mejora. Tome en cuenta los motivos que impulsen una propuesta de proyecto. Debe 
asegurarse de que el proyecto no tiene como propósito mejorar su propia imagen política o 
su poder, o el poder de la persona o grupo que lo proponga, porque hay una alta probabili¬ 
dad de que el proyecto sea mal concebido y, con el tiempo, no tenga una buena aceptación. 

Como se describió en el capítulo 2, es necesario examinar los proyectos potenciales 
desde una perspectiva de sistemas de tal manera que se tome en cuenta el impacto que ten¬ 
drá en toda la organización el cambio propuesto. Recuerde que los diversos subsistemas de 
la organización están interrelacionados y son interdependientes, y que al cambiar un subsis¬ 
tema podría afectar a los demás. A pesar de que los encargados de la toma de decisiones son 
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quienes en última instancia establecen las fronteras del proyecto de sistemas, éste no se de¬ 
be considerar o seleccionar de manera aislada del resto de la organización. 

Más allá de estas consideraciones generales, existen cinco criterios específicos para la 
selección de proyectos: 

1. El respaldo de los directivos de la organización. 

2. Un periodo adecuado de compromiso para terminar el proyecto. 

3. La posibilidad de mejorar la consecución de las metas organizacionales. 

4. Factibilidad en cuanto a recursos para el analista de sistemas y la organización. 

5. La rentabilidad del proyecto en comparación con otras formas en que la organización 

podría invertir sus recursos. 

El principal criterio es el respaldo de los directivos de la organización. Nada se puede 
realizar sin el consentimiento de quienes a la postre proporcionan los recursos económicos. 
Esto no significa que usted carecerá de influencia para dirigir el proyecto o que nadie más, 
aparte de los directivos, puede intervenir; pero el respaldo de estos últimos es primordial. 

Otro criterio importante para seleccionar un proyecto tiene que ver con el estableci¬ 
miento de un periodo adecuado de terminación para usted y la organización. Pregúntese 
a sí mismo y a los demás involucrados si el negocio cuenta con la capacidad de establecer 
un compromiso de tiempo para instalar los nuevos sistemas o mejorar los existentes. Us¬ 
ted también debe comprometer todo su tiempo, o una parte al menos, mientras dure el 
proyecto. 

La posibilidad de contribuir a mejorar la consecución de las metas organizacionales 
constituye el tercer criterio. El proyecto debe servir para que la organización se encarrile, no 
para desviarla de sus metas principales. 

El cuarto criterio es seleccionar un proyecto factible de acuerdo con los recursos y ca¬ 
pacidades con que cuenten tanto usted como la organización. Algunos proyectos estarán 
fuera del alcance de sus conocimientos y usted debe ser capaz de reconocerlo. 

Por último, necesita determinar de manera conjunta con la organización, la valía del 
proyecto de sistemas en comparación con cualquier otro proyecto alternativo. Recuerde 
que cuando un negocio se compromete con un proyecto, le dedica recursos que automáti¬ 
camente quedarán fuera del alcance de otros proyectos. Es muy útil comprender que todos 
los proyectos posibles compiten por los recursos de tiempo, dinero y empleados de la orga¬ 
nización. 


DETERMINACIÓN DE LA VIABILIDAD 

Una vez que la cantidad de proyectos se ha reducido con base en los criterios que acaba¬ 
mos de explicar, queda por determinar si los proyectos seleccionados son viables. Nuestra 
definición de viabilidad es mucho más profunda que la que se le da comúnmente, puesto 
que la viabilidad de los proyectos de sistemas se evalúa de tres maneras principales: opera¬ 
tiva, técnica y económicamente. El estudio de viabilidad no consiste en un estudio comple¬ 
to de los sistemas. Más bien, se trata de recopilar suficientes datos para que los directivos, a 
su vez, tengan los elementos necesarios para decidir si debe procederse a realizar un estudio 
de sistemas. 

Los datos para el estudio de viabilidad se pueden recopilar mediante entrevistas, tema 
que trataremos en detalle en el capítulo 4. El tipo de entrevista apropiado se relaciona di¬ 
rectamente con el problema o la oportunidad bajo análisis. Por lo general, el analista de sis¬ 
temas entrevista a quienes requieren ayuda y a los involucrados en el proceso de toma de 
decisiones, que comúnmente son los directivos. Aunque es importante abordar el problema 
correcto, el analista de sistemas no debe invertir demasiado tiempo en los estudios de via¬ 
bilidad, porque le solicitarán muchos proyectos y sólo unos cuantos podrán o deberán ser 
realizados. El tiempo dedicado al estudio de viabilidad deberá ser bastante reducido y abar¬ 
car diversas actividades. 


FUNDAMENTOS DEL ANALISIS DE SISTEMAS 




DEFINICIÓN DE OBJETIVOS 

El analista de sistemas funge como catalizador y experto de soporte técnico, identificando 
en primer lugar dónde se pueden mejorar los procesos. Desde una perspectiva optimista, las 
oportunidades se pueden considerar como la contraparte de los problemas; más aún, en al¬ 
gunas culturas la crisis también significa oportunidad. Lo que para un gerente podría ser un 
problema inquietante, para un analista de sistemas perceptivo podría convertirse en una 
oportunidad de mejorar. 

Las mejoras a los sistemas se pueden definir como cambios que darán como resultado 
beneficios crecientes y valiosos. Las mejoras pueden ser de muchos tipos, por ejemplo: 

1. Aceleración de un proceso. 

2. Optimización de un proceso al eliminar pasos innecesarios o duplicados. 

3. Combinación de procesos. 

4. Reducción de errores en la captura de información mediante la modificación de formu¬ 
larios y pantallas de despliegue. 

5. Reducción de almacenamiento redundante. 

6. Reducción de salidas redundantes. 

7. Mejora en la integración de sistemas y subsistemas. 

Es importante que el analista de sistemas tenga habilidad para reconocer las oportuni¬ 
dades de mejora. Sin embargo, quienes están en contacto diario con el sistema podrían ser 
fuentes de información más eficaces sobre las mejoras por realizar. Si ya se han sugerido me¬ 
joras, son necesarios sus conocimientos como analista para contribuir a determinar si vale la 
pena la mejora y cómo se debe implementar. 

Es útil para el analista de sistemas elaborar una cuadrícula de impacto de la viabilidad 
(CIV) que le sirva para comprender y evaluarlos impactos (si los hay] que tendrán las me¬ 
joras a los sistemas existentes. En la figura 3.2 se muestra una cuadrícula de este tipo. Los 
rótulos del lado izquierdo describen diversos sistemas existentes o propuestos, que se orga¬ 
nizan en tres categorías de sistemas: de comercio electrónico, de información gerencial 
(MIS) y de procesamiento de transacciones (TPS). En la parte superior se encuentran los 
siete objetivos de los procesos. Las marcas negras denotan que se puede lograr un impacto 
positivo con una mejora al sistema. Las marcas grises indican que el sistema ya se imple¬ 
mento y que la mejora impactó favorablemente el objetivo del proceso. 

Como puede observarse, en casi todos los casos los sistemas de procesamiento de tran¬ 
sacciones muestran un efecto positivo sobre los objetivos de los procesos. Los sistemas de 
información gerencial tradicionales podrían contribuir a tomar mejores decisiones, pero en 
ocasiones no ayudan a la recopilación, almacenamiento y recuperación eficiente de los da¬ 
tos. En consecuencia, hay pocas marcas en esa parte de la cuadrícula. Al ingresar al mundo 
del comercio electrónico, el analista tiene que estar consciente del efecto que podría tener 
sobre los objetivos de los procesos cada mejora que se haga al sistema. Observe que el ana¬ 
lista que llenó esta cuadrícula reconoció que aunque hubo efectos positivos sobre algunos 
objetivos de los procesos, no los hubo en otros. 

También es importante la manera en que las mejoras a los sistemas de información 
afectan los objetivos corporativos. Estos objetivos incluyen: 

1. Mejora de las ganancias corporativas. 

2. Apoyo a la estrategia competitiva de la organización. 

3. Mayor cooperación con distribuidores y socios. 

4. Incremento del apoyo a las operaciones internas con el fin de producir bienes y servi¬ 
cios de manera más eficiente y eficaz. 

5. Incremento del apoyo a la toma de decisiones internas para que éstas sean más eficaces. 

6. Mejora del servicio al cliente. 

7. Incremento en la moral de los empleados. 

Una vez más, una cuadrícula de impacto de la viabilidad es útil para incrementar la 
conciencia de los impactos en el logro de los objetivos corporativos. La cuadrícula que se 
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Un analista puede utilizar una 
cuadrícula de impacto de la 
viabilidad para mostrar cómo 
afectan los componentes del 
sistema a los objetivos de los 
procesos. 
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El componente o la mejora al sistema de información que se propone puede contribuir de manera positiva a los objetivos 
de los procesos si se ¡mplementa en el futuro. 

El componente del sistema de información existente contribuye de manera positiva a los objetivos de los procesos. 


muestra en la figura 3.3 es semejante a la de objetivos de los procesos que describimos an¬ 
tes, pero resalta el hecho de que las mejoras al sistema de información gerencial afectan en 
gran medida los objetivos corporativos. Como recordará, los MIS tradicionales no afectan 
muchos de los objetivos de los procesos, pero por otra parte, sí afectan a la mayoría de los 
objetivos corporativos. 

Es fundamental que el analista realice sistemáticamente los pasos para desarrollar cua¬ 
drículas de impacto de la viabilidad. Al comprender los objetivos de los procesos y los cor¬ 
porativos, el analista se da cuenta de la razón por la cual construye sistemas y entiende la 
importancia que podría tener el diseño de sistemas eficientes y eficaces. El analista puede 
comunicar estos impactos a los encargados de la toma de decisiones que evalúan (y costean) 
el proyecto. 

El analista debe estar consciente que también existen algunos objetivos inaceptables 
para los proyectos de sistemas. Como ya mencionamos, aquí se incluyen los proyectos que 
se emprenden con el único fin de demostrar la capacidad del equipo de análisis de sistemas 
o de imponer la superioridad de un departamento sobre otro para controlar los recursos in¬ 
ternos. Tampoco es aceptable automatizar procedimientos manuales en aras de la simple 
automatización, ni invertir en nueva tecnología debido al deslumbramiento con las caracte¬ 
rísticas avanzadas que ofrece en comparación con las del sistema actual, sin tomar en cuen¬ 
ta su verdadera contribución al logro de las metas de la organización. 
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Símbolo Significado 

/ El componente o la mejora ai sistema de información que se propone puede contribuir de manera positiva a los objetivos 
de los procesos si se implementa en el futuro. 

s/ ^ El componente del sistema de información existente contribuye de manera positiva a los objetivos corporativos. 


Es necesario aclarar de manera formal, por escrito, los objetivos del proyecto, y de ma¬ 
nera informal, a través de conversaciones con los integrantes de la empresa. Averiguar qué 
problema consideran que resolverá el proyecto de sistemas o qué situaciones podría mejo¬ 
rar, y qué esperan del sistema propuesto. 


DETERMINACIÓN DE RECURSOS 

La determinación de recursos para el estudio de viabilidad sigue el mismo patrón general 
que se explicó antes y tendrá que revisarse y evaluarse nuevamente si se autoriza un estudio 
formal de sistemas. Como se muestra en la figura 3.4, un proyecto debe satisfacer tres crite¬ 
rios de viabilidad para pasar a una siguiente fase de desarrollo. Los recursos se analizan des¬ 
de la perspectiva de tres áreas de viabilidad: técnica, económica y operativa. 


Viabilidad técnica Gran parte de la determinación de recursos tiene que ver con la evalua¬ 
ción de la viabilidad técnica. El analista debe averiguar si es posible actualizar o incremen¬ 
tar los recursos técnicos actuales de tal manera que satisfagan los requerimientos bajo con¬ 
sideración. Sin embargo, en ocasiones los "agregados" a los sistemas existentes son costosos y 
no redituables, simplemente porque no cumplen las necesidades con eficiencia. Si no es po¬ 
sible actualizar los sistemas existentes, la siguiente pregunta es si hay tecnología disponible 
que cumpla las especificaciones. 
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Los tres tipos clave de viabilidad 



Los tres tipos clave de viabilidad: 


técnica, económica y operativa. 
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En este punto es benéfico el conocimiento de los analistas de sistemas, ya que éstos po¬ 
drán responder la pregunta de la viabilidad técnica gracias a su propia experiencia y a sus 
contactos con los fabricantes de tecnología. Es común que la respuesta a la pregunta sobre 
si una tecnología específica está disponible y puede satisfacer las necesidades de los usuarios 
sea "sí", y entonces la pregunta pasa al ámbito económico. 

Viabilidad económica La viabilidad económica es la segunda parte de la determinación de 
recursos. Los recursos básicos que se deben considerar son el tiempo de usted y el del equi¬ 
po de análisis de sistemas, el costo de realizar un estudio de .sistemas completo (incluyendo 
el tiempo de los empleados con los que trabajará usted], el costo del tiempo de los emplea¬ 
dos de la empresa, el costo estimado del hardware y el costo estimado del software comer¬ 
cial o del desarrollo de software. 

La empresa interesada debe tener la capacidad de calcular el valor de la inversión bajo 
evaluación antes de comprometerse a un estudio de sistemas completo. Si los costos a corto 
plazo no son opacados por las ganancias a largo plazo o no producen una reducción inme¬ 
diata de los costos operativos, el sistema no es económicamente viable y el proyecto debe 
detenerse. 


Viabilidad operativa Supongamos por un momento que los recursos técnicos y económi¬ 
cos se evaluaron de manera adecuada. El analista de sistemas aún debe considerar la viabili¬ 
dad operativa del proyecto solicitado. La viabilidad operativa depende de los recursos hu¬ 
manos disponibles para el proyecto e implica determinar si el sistema funcionará y será 
utilizado una vez que se instale. 

Si los usuarios están contentos con el sistema actual, no tienen problemas con su mane¬ 
jo y por lo general no están involucrados en la solicitud de un nuevo sistema, habrá una 
fuerte resistencia a la implementación del nuevo sistema. Las posibilidades de que entre en 
funcionamiento son bajas. 

Por el contrario, si los usuarios mismos han expresado la necesidad de un sistema que 
funcione la mayor parte del tiempo, de una manera más eficiente y accesible, hay más pro¬ 
babilidades de que a la larga el sistema solicitado sea utilizado. Como veremos en el capítu¬ 
lo 14, gran parte del éxito para determinar la viabilidad operativa descansa en las interfaces 
de usuario que se elijan. 

En este punto, la determinación de la viabilidad operativa requiere creatividad por parte 
del analista de sistemas, así como de su capacidad de persuasión para indicarle a los usuarios 
cuáles son las probables interfaces y cuáles satisfarán sus necesidades. El analista de sistemas 
también debe escuchar con atención lo que realmente quieren los usuarios y lo que al pare¬ 
cer utilizarán. Sin embargo, a fin de cuentas, la evaluación de la viabilidad operativa se rea¬ 
liza en gran parte con base en la experiencia del analista. 








EVALUACIÓN DE LA VIABILIDAD 


De la explicación anterior se desprende que la evaluación de la viabilidad de los proyec¬ 
tos de sistemas nunca es una tarea sencilla o bien definida. Además, la viabilidad de un pro¬ 
yecto no es una decisión a cargo del analista de sistemas sino de los directivos de la orga¬ 
nización. Las decisiones se toman con base en los datos sobre viabilidad recopilados y 
presentados de una manera experta y profesional por el analista. 

El analista de sistemas debe asegurarse de abordar en el estudio preliminar las tres áreas 
de viabilidad técnica, económica y operativa. El estudio de un proyecto de sistemas solici¬ 
tado debe realizarse con rapidez con el fin de que los recursos que se dediquen a éste sean 
mínimos, la información arrojada por el estudio sea sólida y el interés hacia el proyecto siga 
vigente. Recuerde que se trata de un estudio preliminar, que antecede al estudio del siste¬ 
ma, y debe ejecutarse con rapidez y eficiencia. 

Los proyectos que cumplen los criterios explicados en la subsección "Selección de pro¬ 
yectos" al principio del capítulo, al igual que los tres criterios de viabilidad técnica, econó¬ 
mica y operativa, deben tomarse en cuenta para un estudio de sistemas detallado. En este 
punto el analista de sistemas debe adoptar el rol de experto en soporte técnico e informar a 
los directivos que el proyecto de sistemas solicitado cumple todos los criterios de selección 
y, por lo tanto, constituye un excelente candidato para un estudio más profundo. Recuerde 
que un compromiso por parte de los directivos de la organización en esta etapa tan sólo sig¬ 
nifica que se realizará un estudio de sistemas, no que se aceptará un sistema propuesto. Por 
lo general, el proceso de evaluación de la viabilidad es útil para desechar los proyectos que 
se contraponen con los objetivos de la organización, que desde el punto de vista técnico no 
son factibles y que no ofrecen un aliciente económico. Aunque es muy laborioso, el estudio 
de la viabilidad vale la pena y al final ahorra a las empresas y los analistas de sistemas una 
considerable cantidad de tiempo y dinero. 


PLANEACIÓN Y CONTROL DE ACTIVIDADES 

El análisis y diseño de sistemas involucra muchos tipos diferentes de actividades que en 
conjunto conforman un proyecto. El analista de sistemas debe manejar el proyecto con cui¬ 
dado si desea que éste tenga éxito. La administración de proyectos abarca las tareas genera¬ 
les de planeación y control. 

La planeación incluye todas las actividades requeridas para seleccionar un equipo de 
análisis de sistemas, asignar miembros del equipo a proyectos adecuados, calcular el tiempo 
necesario para realizar cada tarea y programar el proyecto de tal manera que las tareas se 
terminen a tiempo. El control implica el uso de retroalimentación para monitorear el pro¬ 
yecto, incluyendo la comparación del plan original del proyecto con su evolución real. Ade¬ 
más, el control significa emprender las acciones apropiadas para agilizar o reprogramar acti¬ 
vidades para terminar en tiempo, a la vez que estimulen a los miembros del equipo a 
realizar el trabajo de manera profesional. 


CÁLCULO DEL TIEMPO REQUERIDO 

La primera decisión del analista de sistemas es determinar el nivel de detalle necesario pa¬ 
ra definir las actividades. El nivel más bajo de detalle es el ciclo de vida del desarrollo de 
aplicaciones mismo, mientras que el extremo más alto consiste en incluir cada paso en deta¬ 
lle. La respuesta óptima para la planeación y la programación se encuentra en algún punto 
medio. 

Aquí es útil un enfoque estructurado. En la figura 3.5 el analista de sistemas que co¬ 
menzó un proyecto dividió el proceso en tres fases principales: análisis, diseño e implemen- 
tación. A continuación, la fase de análisis se divide a su vez en recopilación de datos, análi¬ 
sis del flujo de datos y de decisiones, y preparación de la propuesta. El diseño se divide en 
diseño de la captura de datos, diseño de la entrada y la salida, y organización de datos. La fa¬ 
se de implementación se divide en implementación y evaluación. 
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Actividad 


Actividad detallada 


Semanas 

requeridas 


Recopilación de catos :. '/ Realizar entrevistas y 1 7 ; 7 ■ ■ : p;7 p. • ■; 3;. •; 

Ap car cuestionarios A 

Leer informes do la compañía ... :4 / 

Introducir prototipos; A" 77;:pp5;ÍKp: 

HilPSPPpPiL 7: : A '.'/, Observar las 'cace onos'hacia los orcr.ot pos • '3 - ■ 


Análisis del flujo de datos 
y de decisiones 


Analizar el flujo de datos 


Preparación de la propuesta Realizar-análisis de costos y beneficios . 3 . 



Preparar la propuesta 2 

Presentar la propuesta ipüP,: 

\ 

\ >■: 



Refinación dé lErglaiijeáCiófiy 7: 

programación de las actividades 
de análisis agregando tareas 
detalladas y estableciendo el : 
tiempo requerido para terminar 
las tareas. 77 . 


Con frecuencia la parte más difícil de la planeación de un proyecto es el paso crucial de 
calcular el tiempo requerido para terminar cada tarea o actividad. Cuando se les preguntan 
las razones de la tardanza en un proyecto específico, los miembros del equipo argumen¬ 
tan cálculos erróneos en la programación que obstaculizan desde el principio el éxito del 
proyecto. Nada reemplaza a la experiencia al momento de calcular el tiempo requerido, y 
los analistas de sistemas que han tenido la oportunidad de pasar por un periodo de aprendi¬ 
zaje son afortunados en este sentido. 

Los encargados de la planeación han intentado reducir la incertidumbre inherente en de¬ 
terminar los estimados de tiempo proyectando estimados más probables, pesimistas y opti¬ 
mistas y aplicando a continuación una fórmula de ponderación del promedio para determinar 
el tiempo esperado que tomará una actividad. Sin embargo, este método no es tan confiable. 
Quizá la estrategia más aconsejable para el analista de sistemas es apegarse a un enfoque es¬ 
tructurado para identificar las actividades y describirlas con suficiente detalle. De esta for¬ 
ma, al menos, podrá reducir la probabilidad de encontrarse con sorpresas desagradables. 


USO DE GRÁFICAS DE GANTT PARA LA PROGRAMACIÓN DE PROYECTOS 


Una gráfica de Gantt es una forma fácil de programar tareas. En este tipo de gráfica las ba¬ 
rras representan cada tarea o actividad. La longitud de cada barra representa la duración re¬ 
lativa de dicha tarea. 

La figura 3.7 es un ejemplo de una gráfica de Gantt bidimensional en la cual el tiempo 
se indica en la dimensión horizontal y la descripción de las actividades se encuentra en la 
dimensión vertical. En este ejemplo la gráfica muestra la fase de análisis o de recopilación 
de información del proyecto. Se observa que tomará tres semanas llevar a cabo las entrevis¬ 
tas, aplicar los cuestionarios tomará cuatro semanas, y así sucesivamente. Estas actividades 
se sobreponen parte del tiempo. El símbolo A en la gráfica significa que la semana actual 
es la 9. Las barras sombreadas representan proyectos o parte de éstos que se han termina¬ 
do, lo cual nos indica que el analista de sistemas está atrasado en la introducción de proto¬ 
tipos, pero adelantado en el análisis de flujo de datos. Deben tomarse medidas inmediatas 
en la introducción de prototipos para evitar que otras actividades o incluso el proyecto 
mismo se atrasen. 

La principal ventaja de la gráfica de Gantt es su sencillez. El analista de sistemas se da¬ 
rá cuenta de que esta técnica no sólo es fácil de utilizar, sino que también es adecuada para 
establecer una comunicación satisfactoria con los usuarios finales. Otra ventaja de utilizar la 
gráfica de Gantt es que las barras representan actividades o tareas a escala; es decir, el tama¬ 
ño de las barras indica el tiempo relativo que tomará completar cada tarea. 
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Actividad 


Uso de una gráfica de Gantt 
bidimensíonal para planear las 
actividades que puedan realizarse 
en paralelo. 


Realizar entrevistas 
Aplicar cuestionarios 
Leer informes de la compañía 
Analizar el flujo de datos 
Introducir prototipos 
Observar las reacciones 
Realizar análisis de costos y beneficios 
Preparar la propuesta 
Presentar la propuesta 



1 2 3 4 5 6 7 8 91011121314151617 1819 20 2122 23 
Á Semanas 


Semana actual 


USO DE DIAGRAMAS PERT 

PERT es un acrónimo de Program Evaluation and Review Techniques (Técnicas de Evalua¬ 
ción y Revisión de Programas). Un programa (sinónimo de proyecto) se representa median¬ 
te una red de nodos y flechas que se evalúa para determinar las actividades críticas, mejorar 
la programación de fechas si es necesario y revisar el progreso una vez que se aborda el pro¬ 
yecto. PERT fue desarrollado a fines de la década de 1950 para utilizarse en el proyecto del 
submarino nuclear Polaris de la Marina de Estados Unidos. Según se dice, ahorró dos años 
de desarrollo a la Marina de Estados Unidos. 

PERT es muy útil cuando las actividades se pueden hacer en paralelo en lugar de en se¬ 
cuencia. El analista de sistemas se puede beneficiar con PERT al aplicarlo a los proyectos de 
sistemas en una escala más pequeña, especialmente cuando algunos miembros de un equi¬ 
po pueden trabajar en ciertas actividades al mismo tiempo que otros miembros del mismo 
equipo trabajan en otras tareas. 

En la figura 3.8 se comparan una gráfica de Gantt sencilla y un diagrama PERT. Las ac¬ 
tividades que se expresan como barras en la gráfica de Gantt, se representan como flechas 


Gráficas de Gantt en comparación 
con diagramas PERT para la 
programación de actividades. 
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en el diagrama PERT. La longitud de las flechas no tiene relación con la duración de las ac¬ 
tividades. Los círculos en el diagrama PERT se denominan eventos y se pueden identificar 
mediante números, letras o con cualquier otra forma de designación. El propósito de los no¬ 
dos circulares es: [1) reconocer cuando una actividad está terminada y [2) indicar las activi¬ 
dades que deben terminarse antes de emprender nuevas actividades [precedencia). 

En realidad la actividad C no puede empezar sino hasta que la actividad A esté termi¬ 
nada. La precedencia no se indica en la gráfica de Gantt, de tal modo que no es posible sa¬ 
ber si la actividad C está programada para iniciar el día 4 a propósito o por coincidencia. 

Un proyecto tiene un inicio, un punto medio y un fin; el inicio es el evento 10 y el fin 
es el evento 50. Para encontrar la duración del proyecto se identifica cada ruta desde el ini¬ 
cio hasta el fin y se calcula la duración de cada ruta. En este ejemplo la ruta 10-20-40-50 
tiene una duración de 15 días, mientras que la de la ruta 10-30-40-50 es de 11 días. Aun 
cuando una persona podría trabajar en la ruta 10-20-40-50 y otra en la ruta 10-30-40-50, el 
proyecto no es una carrera. El proyecto requiere que ambos conjuntos de actividades (o ru¬ 
tas) se terminen; en consecuencia, toma 15 días terminar el proyecto. 

La ruta más larga se denomina ruta crítica. Aunque la ruta crítica se determina calcu¬ 
lando la ruta más larga, ésta se define como la ruta que causará que el proyecto entero se 
atrase incluso si se retrasa un solo día. Observe que si usted se retrasa un día en la ruta 10- 
20-40-50, el proyecto entero se alargará, pero si se retrasa un día en la ruta 10-30-40-50, 
ninguna parte del proyecto lo resentirá. La libertad para retrasarse en algún punto de las ru¬ 
tas no críticas se conoce como tiempo de holgura. 

Ocasionalmente, los diagramas PERT necesitan pseudoactividades, referidas como acti¬ 
vidades simuladas, para preservar la lógica o clarificar el diagrama. La figura 3.9 muestra dos 
diagramas PERT con actividades simuladas. Los proyectos 1 y 2 son un poco diferentes, y la 
forma en que están trazadas las actividades simuladas hace evidente esta diferencia. En el 
proyecto 1 la actividad C sólo puede iniciar si las actividades A y B han terminado, debido 
a que todas las flechas que entran en un nodo deben terminarse antes de abandonar el no¬ 
do. Sin embargo, en el proyecto 2 la actividad C sólo requiere que la actividad B sea termi¬ 
nada y por lo tanto puede iniciar aunque todavía se esté realizando la actividad A. 

Completar el proyecto 1 toma 14 días, mientras que para el proyecto 2 tan sólo son ne¬ 
cesarios 9 días. Por supuesto, en el proyecto 1 es necesaria la actividad simulada, debido a 
que indica una relación crucial de precedencia. Por otro lado, en el proyecto 2 no se requie¬ 
re la actividad simulada, y la actividad A se podría haber trazado del 10 al 40 y se podría ha¬ 
ber eliminado por completo el evento 20. 



Proyecto 1 


Proyecto 2 



Cuando se utiliza un diagrama 
PERT es importante la 
precedencia: de actividades 
para determinar la duración 
del proyecto. 
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Lista de actividades que se usan 
para dibujar un diagrama PERT, 


Actividad Predecesor Duración 

'• .A ."Realizar entrevistas ■' .Ninguno ' 3 

■ *3 Aplicar cuestionarios AA- -T v ; A;vv\t '.; : 'v ; 4 
C Lee' nlormes de la compañ a Ninguno 4 

D Analizar el flujo de. datos a -; B: C ■ 8 

. , E" Introducir prototipos.; ATa ) A:-. : B. C L (Uy a:5" : : 

Observar las reacciones hacia el prototipo F 3. 

G. Realizar anahsis de costos y beneficios D 3 

.H Preparar la propuesta . j ' ' KG 2 

Presentar la. propuesta::: .;Á:í KyiAyiA 2 


Por lo tanto, hay varias razones para utilizar el diagrama PERT en vez de la gráfica de 
Gantt. El diagrama PERT permite: 

1. Identificar fácilmente el orden de precedencia. 

2. Identificar fácilmente la ruta crítica y por consiguiente las actividades críticas. 

3. Determinar fácilmente el tiempo de holgura. 

Un ejemplo de PERT Suponga que un analista de sistemas está tratando de establecer un 
programa realista para las fases de recopilación de datos y de propuestas del ciclo de vida 
del análisis y diseño de sistemas. El analista de sistemas revisa la situación y lista las activi¬ 
dades que deben realizarse. Esta lista, que se muestra en la figura 3.10, refleja que algunas 
actividades deben preceder a otras. Las estimaciones de tiempo se calcularon de la manera 
que se explicó en una sección previa de este capítulo. 

Cómo dibujar un diagrama PERT Al construir un diagrama PERT, el analista considera pri¬ 
mero aquellas actividades que no requieren actividades predecesoras, en este caso A (realizar 
entrevistas) y C (leer informes de la compañía). En el ejemplo de la figura 3.11, el analista 
eligió numerar los nodos como 10, 20, 30, etc., y trazó dos flechas que parten del nodo 10 
inicial. Estas flechas representan las actividades A y C, por lo que se les asignan estos nom¬ 
bres. Los nodos 20 y 30 se dibujan al final de estas flechas, respectivamente. El siguiente pa¬ 
so es buscar cualquier actividad que sólo requiera a A como predecesor; la tarea B (aplicar 
cuestionarios) es la única que lo requiere, de modo que se puede representar trazando una 
flecha del nodo 20 al 30. 

Debido a que las actividades D (analizar el flujo de datos) y E (introducir prototipos) 
requieren, para poder empezar, que las actividades B y C hayan terminado, las flechas D y E 
se trazan desde el nodo 30, el evento que reconoce la finalización de B y C. Este proceso 
continúa hasta terminar todo el diagrama PERT. Observe que el proyecto entero finaliza en 
el evento denominado nodo 80. 

Cómo identificar la ruta crítica Una vez que se ha dibujado el diagrama PERT, es posible 
identificar la ruta crítica calculando la suma de la duración de las actividades de cada ruta y 



Diagrama; PERT completo para 
la fase de análisis de un proyecto. 
oe sistemas. 
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eligiendo la ruta más larga. En este ejemplo hay cuatro rutas: 10-20-30-50-60-70-80, 10- 
20-30-40-60-70-80,10-30-50-60-70-80 y 10-30-40-60-70-80. La ruta más larga es 10-20- 
30-50-60-70-80, que toma 22 días. Es esencial que el analista de sistemas vigile cuidadosa¬ 
mente las actividades de la ruta crítica para que todo el proyecto esté a tiempo o incluso 
que acorte su duración si fuera posible. 


PROGRAMACION DE PROYECTOS POR C0ÍP0TAD0RA 

La programación de proyectos con ayuda de las computadoras se ha convertido en una ta¬ 
rea práctica y sencilla. Microsoft Project es un buen ejemplo de un programa muy eficaz. 

En la figura 3.12 se puede ver un ejemplo de administración de proyectos con Micro¬ 
soft Project. Es posible introducir nuevas tareas en la parte superior o en la inferior de la 
pantalla (lo que resulte más fácil para el usuario). Supongamos que deseamos introducir 
la tarea "Realizar análisis de necesidades" (Conduct needs analysis) en la parte inferior de la 
pantalla. Primero, introducimos el nombre de la actividad, luego su duración, 5d (incluyen¬ 
do un calificador: d para día, s para semana, etc.) y el ID de cualquier predecesor. El ID, o 
identificador, es simplemente el número de la tarea. No necesitamos introducir una fecha 
de inicio si deseamos que el programa de la computadora lo programe por nosotros (tan 
pronto como sea posible, dados los predecesores). La parte superior izquierda de la tabla lis¬ 
ta las actividades en el orden en que las introdujimos. En la parte superior derecha se mues¬ 
tra una gráfica de Gantt. 

La figura 3.13 es otra pantalla de Microsoft Project. La parte superior muestra ahora un 
diagrama PERT. Microsoft Project representa las tareas o actividades con rectángulos en lu¬ 
gar de flechas. Aunque esto va contra las convenciones tradicionales utilizadas en los diagra¬ 
mas PERT, los autores del software consideran que es más fácil leer las tareas en cuadros 
rectangulares que en flechas. Una línea remarcada (desplegada en rojo en la pantalla original 
del programa) indica la ruta crítica. Una vez que las actividades se dibujan en la pantalla, se 
pueden reposicionar mediante el ratón para incrementar la legibilidad y la comunicación 
con otros. El cuadro oscuro indica que ahora estamos observando esa actividad. La línea 
vertical punteada en la parte izquierda de la pantalla muestra al usuario dónde ocurrirá el 
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salto de página. Cualquiera que utilice los productos de Microsoft está familiarizado con los 
iconos en la parte superior de la página. 

PUNTO DE ENTREGA (TI MEB0X1NG) 

El punto de entrega es un desarrollo reciente en la administración de proyectos. Tradicional¬ 
mente, un proyecto se divide en fases, hitos y tareas, pero el enfoque de punto de entrega uti¬ 
liza una fecha de vencimiento absoluta para el proyecto y todo lo que se haya realizado al 
término de esa fecha se debe implementar. Es importante establecer una fecha de venci¬ 
miento razonable según el tamaño y las metas del proyecto. También, es necesario priorizar 
las metas del proyecto con el propósito de entregar a los usuarios las más importantes a la 
fecha de vencimiento. Las metas menos importantes pueden ser implementadas posterior¬ 
mente en el proyecto. Un ejemplo de punto de entrega (timeboxing) es crear un sitio Web 
que contenga las características más importantes, aún y cuando algunas páginas de menor 
importancia muestren la imagen "En construcción". 

Otros enfoques para la programación incluyen los administradores de información per¬ 
sonal integrados o PIMs [personal information managers). Algunos ejemplos de PIM son 
Microsoft Outlook y Palm Desktop. Estos PIMs son útiles debido a que sirven como depó¬ 
sito para los números telefónicos y de fax de los socios de negocios; para los planificadores 
diarios, semanales o mensuales, y para las listas de pendientes. Algunos PIMs están diseña¬ 
dos para servir como shells que permiten arrancar otros programas e incluso permiten alma¬ 
cenar datos similares provenientes de programas de procesamiento de texto y de hoja de 
cálculo en carpetas organizadas sobre un tema específico. Algunos son buenos para compartir 
datos con otros programas, mientras que otros incluyen gráficas de Gantt para apoyar la ad¬ 
ministración de proyectos. La mayoría de los PIMs se puede sincronizar con PIMs de compu¬ 
tadoras Palm y otros dispositivos portátiles, teléfonos celulares y relojes, permitiendo una 
excelente portabilidad inalámbrica. 
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lunto con la administración del tiempo y los recursos, los analistas de sistemas también de¬ 
ben administrar gente. La administración se realiza principalmente mediante una comuni- 
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cación precisa con los miembros del equipo que se han seleccionado por su capacidad y 
compatibilidad. Se deben establecer las metas para la productividad del proyecto, y es nece¬ 
sario motivar a los miembros de los equipos de análisis de sistemas para que las alcancen. 

ESTRATEGIAS DE COMUNICACIÓN PARA ADMINISTRAR EQUIPOS 

Los equipos tienen su propia personalidad, resultado de la combinación de cada uno de los 
miembros individuales del equipo con los demás miembros de una manera que crea una red 
de interacciones totalmente nueva. Una forma de estructurar la manera en que concibe a los 
equipos es visualizarlos siempre en una búsqueda constante de equilibrio entre la consecu¬ 
ción de las tareas en turno y el mantenimiento de las relaciones entre los miembros del 
equipo. 

De hecho, por lo regular los equipos tendrán dos líderes, no sólo uno. Generalmente 
una persona se encargará de guiar a los miembros a la consecución de tareas, y otra se ocu¬ 
pará de las relaciones sociales entre los miembros del grupo. Ambos son necesarios para el 
equipo. Algunos investigadores han denominado a estos individuos como líder de tareas y lí¬ 
der socioemocional, respectivamente. Todos los equipos padecen las tensiones derivadas de la 
búsqueda de un equilibrio entre la consecución de las tareas y el mantenimiento de las re¬ 
laciones entre los miembros del equipo. 

Para que continúe la eficiencia del equipo, es necesario solucionar continuamente las 
tensiones. Si se resta importancia a las tensiones o se ignoran, éstas conducirán a la ineficien¬ 
cia y a la desintegración eventual del equipo. Gran parte de la liberación de la tensión se 
puede lograr mediante un uso inteligente de la retroalimentación por todos los miembros 
del equipo. Sin embargo, todos los miembros deben estar de 'acuerdo en que la forma en 
que interactúan (es decir, los procesos) es suficientemente importante para ameritar algún 
tiempo. Las metas de productividad para los procesos se explican en una sección posterior. 

Para garantizar el acuerdo sobre la interacción apropiada entre los miembros es necesaria 
la creación de normas explícitas e implícitas (expectativas, valores y formas de comporta¬ 
miento colectivos) que guíen las relaciones entre los miembros. Las normas son exclusivas 
de los equipos y no es necesario que se transfieran de un equipo a otro. Estas normas cam¬ 
bian constantemente y es mejor considerarlas como un proceso de interacción de los equi¬ 
pos y no como un producto. 

Las normas pueden ser funcionales o disfuncionales. El hecho de que un comporta¬ 
miento particular sea una norma para un equipo no significa que le ayudará a conseguir sus 
metas. Por ejemplo, la expectativa de que los miembros más recientes de un equipo se en¬ 
carguen de toda la programación del proyecto podría ser una norma de equipo. Al apegarse 
a esta norma, el equipo ejercería una fuerte presión sobre los miembros más nuevos y no 
aprovecharía la experiencia de los demás miembros del equipo. Esta es una norma que, de 
continuar, podría ocasionar que los miembros del equipo desperdiciaran recursos valiosos. 

Los miembros del equipo necesitan hacer explícitas las normas y evaluar periódicamente 
si dichas normas son funcionales o disfuncionales para ayudar al equipo a conseguir sus metas. 
La expectativa más importante para su equipo debe ser que el cambio es la norma. Pregún¬ 
tese si las normas del equipo están fomentando u obstaculizando el progreso del equipo. 

FIJACIÓN DE LAS METAS DE PRODUCTIVIDAD DEL PROYECTO 

Cuando ha trabajado con los miembros de su equipo en diferentes tipos de proyectos, usted 
o el líder de su equipo adquirirán habilidad para proyectar lo que puede conseguir el equi¬ 
po en un periodo específico. Al utilizar las sugerencias descritas en la sección sobre métodos 
para calcular el tiempo requerido y aplicándolas de manera conjunta con la experiencia el 
equipo podrá fijar metas de productividad benéficas. 

Los analistas de sistemas están acostumbrados a las metas de productividad para em¬ 
pleados que muestran salidas tangibles, tales como el número de pantalones vaqueros azules 
cosidos por hora, el número de entradas capturadas por minuto, o el número de artículos es- 
caneados por segundo. Sin embargo, conforme se incrementa la productividad en la ma¬ 
nufactura, está claro que la productividad del área administrativa debe incrementarse 
también. Con esta finalidad en mente se fijan las metas de productividad para el equipo de 
análisis de sistemas. 
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SJ OPORTUNIDAD DE CONSULTARÍA 3.3 


CUIDADO AL ESTABLECER METAS 


"Esto es lo que considero que podemos realizar durante las cinco 
semanas siguientes", dice Hy, el líder de su equipo de análisis de siste¬ 
mas, al tiempo que muestra con seguridad un programa con los nombres 
de cada uno de los miembros del equipo junto a una lista de metas a cor¬ 
to plazo. Apenas hace una semana su equipo de análisis de sistemas 
sostuvo una intensa reunión con el propósito de acelerar el programa del 
proyecto para los Redwings de Kitchener, Ontario, un equipo de hockey 
cuya directiva está ejerciendo presión sobre ustedes para que produzcan 
un prototipo. 

Los otros tres miembros del equipo miran la gráfica con asombro. Fi¬ 
nalmente, Rip, uno de los miembros, dice: "Estoy sorprendido. Cada uno 
de nosotros tiene tanto que hacer, y ahora esto”. 

Hy contesta a la defensiva: "Debemos ser agresivos, Rip. Ellos están 
fuera de temporada. Es la única época en que están disponibles. Si fija¬ 
mos nuestras metas demasiado bajas, no terminaremos el prototipo del 
sistema, mucho menos el sistema mismo, antes de que empiece la tem¬ 
porada de hockey. La idea es dar a los Redwings la ventaja sobre la com¬ 
petencia mediante el uso de su nuevo sistema". 

Flona, otro miembro del equipo, interviene en la discusión: "¡Dios sa¬ 
be que sus jugadores no pueden darles eso!" Fiona se detiene para escu¬ 


char los gruñidos acostumbrados del grupo reunido, y continúa: "Ha¬ 
blando en serio, estas metas son fatales. Al menos habrías podido pre¬ 
guntarnos qué pensamos, Hy. Incluso, quizá sepamos mejor que tú lo que 
es posible". 

"Estamos ante un problema apremiante, no en una merienda, Fio¬ 
na", contesta Hy. "No podía realizar un sondeo amable entre los 
miembros del equipo. Tenía que hacer algo rápidamente. Así que tomé 
esta decisión. Propongo que enviemos nuestro programa a ía gerencia 
con base en esto. Podemos recorrer las fechas límite posteriormente si 
tenemos que hacerlo. Pero de esta forma ellos sabrán que estamos 
comprometidos a realizar un gran esfuerzo antes de que empiece la 
temporada”. 

En su calidad de cuarto miembro del equipo, elabore tres sugeren¬ 
cias que podrían ayudar a Hy a mejorar la manera en que aborda la 
creación y presentación de metas. ¿Qué tan motivado cree que estará el 
equipo si sus miembros comparten la opinión de Fiona respecto a las 
metas de Hy? ¿Guales son las posibles consecuencias de presentarle a 
los directivos metas demasiado optimistas? Describa en un párrafo los 
efectos a corto plazo, y en otro párrafo los efectos a largo plazo, de esta¬ 
blecer metas demasiado elevadas y poco realistas. 


Es necesario que el equipo formule las metas y esté de acuerdo con ellas, y que lo haga 
con base en la experiencia de todos sus miembros, el desempeño anterior y la naturaleza del 
proyecto específico. Las metas variarán un poco para cada proyecto que se emprenda, por¬ 
que en ocasiones el proyecto consistirá en la instalación de un sistema completo, y en otros 
casos tal vez sólo se realicen algunas modificaciones a una parte de un sistema existente. 


líSsIl» L I 


MOTIVACION A LOS MIEMBROS DEL EQUIPO DE UN PROYECTO 

A pesar de que la motivación es un tema sumamente complejo, en este punto es importan¬ 
te considerarlo, aun cuando sea de manera breve. Recordemos que los individuos se agrupan 
en organizaciones para satisfacer algunas de sus necesidades básicas como el cobijo, vestido 
y sustento. No obstante, todos tenemos también necesidades más elevadas, como la perte¬ 
nencia a un grupo, el control, la independencia y la creatividad. Todos los individuos tene¬ 
mos motivación para satisfacer necesidades en diversos aspectos. 

Los miembros de un equipo se pueden motivar, al menos en parte, involucrándolos en 
la fijación de metas, como vimos en la sección anterior. El simple acto de fijar una rneta de¬ 
safiante pero alcanzable y de medir periódicamente el desempeño contra la meta estableci¬ 
da parece eficaz para motivar a los individuos. Las metas sirven como imanes para atraer a 
los individuos a la consecución de éstas. 

Parte de la razón de que la fijación de metas motive a los individuos consiste en que los 
miembros de un equipo saben exactamente lo que se espera de ellos con antelación a cual¬ 
quier revisión del desempeño. El éxito de la fijación de metas con el fin de motivar también 
se puede conseguir dando un poco de autonomía a cada miembro del equipo para la conse¬ 
cución de las metas. Aunque una meta se fija de antemano, tal vez no ocurra lo mismo con 
los medios para alcanzarla. En este caso los miembros del equipo tienen libertad para recu¬ 
rrir a sus propios conocimientos y experiencia para cumplir sus metas. 

La fijación de metas también puede motivar a los miembros del equipo pues les aclara 
tanto a ellos como a los demás lo que se tiene que hacer para conseguir resultados. Asimis¬ 
mo, las metas motivan a los miembros del equipo porque definen el grado de éxito que se 
espera de ellos. Esta forma de utilizar las metas simplifica la atmósfera laboral, pero también 
la estimula con la perspectiva de que lo esperado se puede conseguir. 
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ADMINISTRACIÓN DE PROYECTOS CON SOFTWARE COMERCIAL 


En ocasiones se utiliza software comercial (COTS, commercial off-the-shelf) para terminar 
más rápido un proyecto o para reducir el riesgo. Aún así, la administración de estos proyec¬ 
tos requiere una cuidadosa planeación. 

Algunos conocedores definen en un sentido muy amplio el software comercial. Es de¬ 
cir, consideran software comercial a un rango muy amplio de paquetes, como Microsoft 
Word y Microsoft Access. Por lo tanto, el software comercial para PC incluye a los paquetes 
antivirus, al software gráfico y a los programas para el manejo de impuestos. Otros conoce¬ 
dores definen al software comercial como específico de la industria. Sin embargo, a fin de 
cuentas es lo mismo: en vez de escribir el código de sus propios programas, usted simple¬ 
mente adopta estos paquetes. 

Los paquetes de software comercial permiten cierto grado de personalización. Las ma- 
cros y las plantillas dan la posibilidad de personalizar el software para una empresa en par¬ 
ticular. Sin embargo, los paquetes de software comercial tienen problemas frecuentes de 
compatibilidad y no funcionan bien en conjunto. De hecho, antes de la aparición de Win¬ 
dows XP la instalación de un paquete deshabilitaba a otros paquetes (los autores de este 
libro padecieron muchas veces este problema). Pero incluso ahora, dos paquetes de Word¬ 
Perfect Corporation (CorelDraw Graphics Suite y Corel Designer] tienen combinaciones 
de teclas y comandos que no coinciden de un programa a otro. Dado que una de las su¬ 
puestas ventajas de los paquetes de software comercial es que facilitan la capacitación de 
los usuarios, esta falta de coherencia en las combinaciones de teclas y comandos es una 
contradicción. 

PeopleSoft es un paquete de software comercial muy popular en muchas universidades. 
Este paquete se analizará en el capítulo 6, y en el capítulo 10 se verán otros paquetes de 
apoyo a la toma de decisiones. 


ADMINISTRACIÓN DE PROYECTOS DE COMERCIO ELECTRÓNICO 


Muchos de los enfoques y técnicas que acabamos de explicar se aplican también a la admi¬ 
nistración de proyectos de comercio electrónico. No obstante, tome en cuenta que aunque 
tienen muchas semejanzas, también cuentan con muchas diferencias. Una de estas últimas 
consiste en que los datos utilizados por los sistemas de comercio electrónico se encuentran 
dispersos en toda la organización. Por lo tanto, usted no sólo administrará datos de un de¬ 
partamento independiente o incluso de una sola unidad. De ahí que entrare enjuego la po¬ 
lítica de la organización, ya que con frecuencia las unidades tienden a proteger los datos que 
generan y no entienden la necesidad de compartirlos con todos. 

Otra diferencia marcada es que los equipos de proyectos de comercio electrónico por 
lo general necesitan más personal con habilidades diversas, incluyendo desarrolladores, con¬ 
sultores, expertos en bases de datos e integradores de sistemas, de toda la organización. Los 
grupos de proyectos bien definidos y equilibrados dentro de un grupo de sistemas de infor¬ 
mación o dentro de un equipo de desarrollo de sistemas serán la excepción más que la re¬ 
gla. Además, debido a que inicialmente podría requerirse mucha ayuda, los gerentes de pro¬ 
yectos de comercio electrónico requieren establecer acuerdos de cooperación tanto interna 
como externamente mucho antes de la implementación, por ejemplo, compartiendo el ta¬ 
lento, con el propósito de sufragar los costos de las implementaciones de comercio electró¬ 
nico y reunir a los individuos que tengan los conocimientos adecuados. El peligro de que los 
juegos políticos de la organización dividan a los miembros de un equipo es muy real. 

Una manera de impedir que la política boicotee un proyecto consiste en que el gerente 
del proyecto de comercio electrónico ponga énfasis en la integración del comercio electró¬ 
nico con los sistemas internos de la organización, y que al hacerlo también resalte el aspecto 
organizacional implícito en el proyecto de comercio electrónico. Como un gerente de pro¬ 
yecto de comercio electrónico nos manifestó: "El diseño de la interfaz [lo que ve el cliente] 
es la parte sencilla del problema. El verdadero reto está en integrar estratégicamente el 
comercio electrónico con todos los sistemas de la organización". 

Una cuarta diferencia entre la administración de proyectos tradicionales y la adminis¬ 
tración de proyectos de comercio electrónico radica en que, como el sistema se enlazará con 
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el mundo externo a través de Internet, la seguridad es de extrema importancia. El desarro¬ 
llo y la implementación de un plan de seguridad antes de que el nuevo sistema esté en fun¬ 
cionamiento es un proyecto en sí mismo y debe manejarse como tal. 


CÓMO EVITAR EL FRACASO DE UN PROYECTO 

Por lo general, las primeras conversaciones que sostenga con los directivos y demás involu¬ 
crados en la solicitud de un proyecto, junto con los estudios de viabilidad que realice, son 
sus mejores defensas para rechazar proyectos que tengan una alta probabilidad de fracaso. 
La práctica y la experiencia mejorarán su capacidad para evaluar si un proyecto vale la pena 
y las razones que motivan a los demás a solicitarlo. Si usted es miembro de un equipo inter¬ 
no de análisis de sistemas, debe mantenerse al tanto del clima político de la organización, así 
como de su situación financiera y competitiva. 

También puede aprender de la experiencia adquirida por las personas involucradas en 
los fracasos de proyectos anteriores. Al pedirle a programadores profesionales que expli¬ 
quen las razones por las cuales han fallado algunos proyectos, argumentan la fijación de fe¬ 
chas irreales o imposibles de cumplir por parte de los directivos, la creencia de que basta 
con incorporar más gente a un proyecto para acelerarlo (a pesar de que la fecha original pa¬ 
ra la terminación del proyecto era irreal], y la actitud irreflexiva de los directivos al prohibir 
al equipo que recurra al conocimiento de profesionales externos en busca de ayuda para so¬ 
lucionar problemas específicos. 

Recuerde que no recae en usted toda la responsabilidad de tomar la decisión de dar 
inicio a un proyecto. A pesar de que su equipo de análisis de sistemas hace sugerencias, los 
directivos son quienes deciden si un proyecto propuesto es digno de un estudio más profun¬ 
do (es decir, de una mayor inversión de recursos]. El proceso de toma de decisiones de su 
equipo debe ser abierto y soportar el análisis minucioso de quienes no pertenecen a él. Los 
miembros del equipo deben estar conscientes de que su reputación y permanencia en la or¬ 
ganización dependen estrechamente de los proyectos que acepten. 


PiOYECTOS D E p ro i RAi AC1 8 N EXTREMA 


La programación extrema (XP] es un enfoque de desarrollo de sistemas que acepta lo que 
conocemos como buenas prácticas de desarrollo de sistemas y las lleva al extremo. En el ca¬ 
pítulo 6 exploraremos XP con más detalle, pero es muy importante en este capítulo, porque 
la programación extrema también implica la administración de proyectos de XP. 

Esta sección se consagra a las técnicas de XP que garantizan que el proyecto se termi¬ 
nará a tiempo. Las cuatro variables que un desarrollador de sistemas puede controlar son el 
tiempo, el costo, la calidad y el alcance. Cuando estas cuatro variables de control se incluyen 
de manera apropiada en la planificación, se genera un estado de equilibrio entre los recur¬ 
sos y las actividades que se requieren para terminar el proyecto. En la figura 3.14 se de¬ 
muestra este equilibrio. 

Las actividades de XP consisten en codificar, probar, escuchar y diseñar. Por supuesto, la 
codificación es esencial en cualquier proyecto de software. Las pruebas de funcionalidad, 
desempeño y conformidad son obligatorias. La actividad de escuchar al cliente y otros pro¬ 
gramadores y analistas es fundamental. El diseño de un sistema funcional, estético y al cual 
se le pueda dar mantenimiento es extremadamente importante. 

La principal diferencia entre la administración de proyectos de XP y otros tipos de ad¬ 
ministración de proyectos más tradicionales es que al escuchar lo que desean los usuarios, 
usted puede calcular la cantidad que se requerirá de cada recurso. Con el fin de equilibrar 
los resultados del proyecto, el analista de XP puede ajustar cualquiera de las cuatro varia¬ 
bles de recursos. 

Por ejemplo, la filosofía de XP asume que si el analista determina el alcance, la calidad 
y el tiempo necesarios para terminar el proyecto, puede ajustar el costo. Si el proyecto está 
retrasado, tan sólo tiene que incrementar el gasto contratando a más personas. Por otro lado. 
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actividades, i un proyecto de XP 
probablemente cumplirá sus 
metas. 

si el analista determinara de antemano la cantidad de tiempo, la calidad y el costo que se re¬ 
quieren, podría ajustar el alcance. En este último caso, si el proyecto estuviera retrasado, tal 
vez el analista tendría que consultar con el cliente para omitir alguna característica, por 
ejemplo. 

Es evidente que el control de los recursos de esta manera es extremo. ¿De eso se trata, 
no es así? La filosofía de XP es ser extrema. A continuación ilustraremos que pensar de ma¬ 
nera extrema y actuar de manera extrema son dos cosas diferentes. La siguiente subsección 
analiza con más detalle la manera de ajustar cada una de las variables de control de recursos. 


BALANCE DE LOS RECURSOS DE LA PROGRAMACIÓN EXTREMA 

Es admirable terminar a tiempo todas las actividades del proyecto a pesar de todas las res¬ 
tricciones, pero, como tal vez ya se haya dado cuenta, para lograrlo es crucial la administra¬ 
ción del proyecto. La administración de un proyecto no significa simplemente conjuntar todas 
las tareas y recursos. También significa que el analista se enfrenta con varias decisiones para 
balancear los niveles de cada recurso. A veces el costo puede determinarse de antemano, en 
otras situaciones el tiempo podría ser el factor más importante. A continuación se explican 
estas variables de control de recursos (tiempo, costo, calidad y alcance). 


Tiempo Es necesario dedicar suficiente tiempo a la terminación de un proyecto. Sin em¬ 
bargo, el tiempo se asigna a actividades separadas. Se debe dedicar tiempo para escuchar a 
los clientes, tiempo para diseñar, tiempo para codificar y tiempo para probar. 

Uno de nuestros amigos es propietario de un restaurante chino. Hace algún tiempo se 
enfrentó a una falta de personal debido a que uno de sus empleados más confiables regresó 
a Hong Kong para casarse. Nuestro amigo se ubicó en la cocina y consiguió que la comida se 
sirviera a tiempo, pero dejó de saludar a los clientes a la entrada como lo hacía regularmen¬ 
te. Sacrificó la actividad de escuchar para lograr otra, pero se dio cuenta de que esto perju¬ 
dicaba a su negocio. Los clientes reclamaban su atención. 
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Para equilibrar los recursos con 
las actividades, el analista de XP 
podría optar por poner más peso 
en una variable de control de 
recursos específica como el costo. 



En el desarrollo de sistemas ocurre lo mismo. Se puede crear software de calidad, pero 
fracasar al escuchar. Se puede diseñar un sistema perfecto, pero no dedicar tiempo suficien¬ 
te para probarlo. Es difícil administrar el tiempo. ¿Si estuviera en una situación en la que le 
faltara tiempo, qué haría usted? 

La XP desafía la idea de que más tiempo le permitirá obtener los resultados que desea. 
Quizás el cliente preferiría que usted terminara a tiempo en lugar de extender la fecha lími¬ 
te para agregar otra función al sistema. Con frecuencia nos ha ocurrido que los clientes se 
sienten felices si parte de la funcionalidad queda lista a tiempo. Según nuestra experiencia, 
un cliente queda 80 por ciento satisfecho con el primer 20 por ciento de la funcionalidad. 
Esto significa que cuando usted termina el 80 por ciento final del proyecto, el cliente sólo 
estará ligeramente más feliz que cuando usted terminó el primer 20 por ciento. El mensaje 
aquí es que tenga cuidado de no extender su fecha límite. El método de XP insiste en ter¬ 
minar a tiempo. 

Costo El costo es la segunda variable que podemos ajustan Observe que en la figura 3.15 
mostramos que el costo puede usarse para equilibrar el proyecto. Las actividades de codifi¬ 
car, diseñar, probar y escuchar están sobrecargando el proyecto, y los recursos que pusimos 
en tiempo, alcance y calidad no son suficientes para equilibrar el proyecto, a pesar de haber 
asignado una cantidad normal al costo. El recurso del costo requerido debe estar bastante 
arriba del promedio. Observe en la figura que el total de alcance, tiempo y calidad "pesa" 
225 kg y necesitaría un peso de 175 kg, bastante arriba del promedio, para equilibrar los 
400 kg del lado derecho de la balanza. Fundamentalmente, necesitamos aportar más recur¬ 
sos en dinero para equilibrar el proyecto. 

La manera más sencilla de aumentar el gasto (y por ende los costos] es contratar a más 
personas. Esta podría parecer la solución perfecta. Si contratamos a más programadores, ter- 
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minaremos más rápido. ¿No es verdad? No necesariamente. Imagine que contrata a dos per¬ 
sonas para reparar un techo y que después contrata a dos más. Pronto, los trabajadores esta¬ 
rán tropezando entre sí. Además, tienen que preguntarse uno a otro qué falta por hacer. Y 
si empieza a caer una tormenta, nadie podrá trabajar. Asignar el doble de personas no sig¬ 
nifica que las cosas se harán en la mitad del tiempo. Cuando esté ante la disyuntiva de con¬ 
tratar a más personal, tome en cuenta la cantidad adicional de comunicación y otros costos 
intangibles que requerirá. Recuerde que cuando alguien se une a un equipo, no conoce el pro¬ 
yecto ni al equipo. Estos miembros nuevos atrasarán a los miembros ya existentes del equi¬ 
po, puesto que estos últimos tendrán que dedicar tiempo para poner al tanto a los recién 
ingresados. 

El tiempo extra tampoco ayuda mucho. Aumenta el costo, pero no siempre incremen¬ 
ta la productividad. Los programadores cansados son menos eficaces que los programadores 
alertas. Los programadores cansados tardan más tiempo para completar una tarea, y tam¬ 
bién cometen errores que requieren aún más tiempo para arreglarlos. 

¿Hay algo más en lo que podamos invertir nuestro dinero? Quizás. Conforme lea los 
capítulos posteriores conocerá diversas herramientas que apoyan a los analistas y a los pro¬ 
gramadores. A menudo es aconsejable invertir en estas herramientas. Por ejemplo, los analis¬ 
tas usan paquetes gráficos como Microsoft Visio y Corel Designer para comunicar a otros 
sus ideas sobre el proyecto, y las herramientas CASE como Visible Analyst también contri¬ 
buyen a acelerar los proyectos. 

Incluso el nuevo hardware podría ser un gasto redituable. Las computadoras portátiles 
y teléfonos celulares mejoran la productividad fuera de la oficina. Pantallas más grandes, te¬ 
clados y ratones habilitados para la tecnología Bluetooth y taijetas de gráficos más potentes 
también pueden aumentar la productividad. 

Calidad La tercera variable de control de recursos es la calidad. Si los sistemas ideales son 
perfectos, ¿por qué se pone tanto esfuerzo en el mantenimiento de sistemas? ¿Ya estamos 
practicando XP al sacrificar la calidad en el desarrollo de software? En el capítulo 16 vere¬ 
mos la enorme importancia de la calidad y los métodos (como TQM y Seis Sigma) que ayu¬ 
dan a asegurar la calidad del software. 

Sin embargo, la filosofía de XP permite al analista ajustar este recurso, y quizá poner 
menos esfuerzo del esperado en mantener la calidad. La calidad puede ajustarse tanto inter¬ 
na como externamente. La calidad interna involucra probar factores del software como la 
funcionalidad (¿el programa hace lo que se supone que debe hacer?) y la conformidad (¿el 
software cumple ciertas normas de conformidad y se le puede dar mantenimiento?). Por lo 
general no es conveniente escatimar la calidad interior. 

Eso nos deja con la calidad externa, o cómo el cliente percibe el sistema. Al cliente le 
interesa el desempeño. Las siguientes son algunas de las preguntas que podría hacer un 
cliente: ¿El programa funciona de manera confiable (o aún existen bugs, o problemas, en el 
software)? ¿Es eficaz el resultado? ¿Recibo a tiempo los resultados? ¿El software se ejecuta 
sin esfuerzo? ¿La interfaz de usuario se entiende y usa con facilidad? 

La filosofía extrema de XP permite sacrificar algunos de los aspectos de calidad exter¬ 
nos. Para que el sistema sea liberado a tiempo, quizá el cliente tenga que lidiar con algunos 
bugs del software. Si queremos cumplir nuestra fecha límite, tal vez la interfaz de usuario no 
sea perfecta. La podemos refutar en una versión posterior. 

Los fabricantes de software comercial sacrifican la calidad, y es discutible si este enfo¬ 
que es correcto. Pero los programadores extremos tienen libertad para tomar medidas extre¬ 
mas. Así que no se sorprenda si las aplicaciones de software de su PC (sin mencionar su sis¬ 
tema operativo y su navegador Web) son actualizadas a menudo. 


Alcance Por último, tenemos el alcance. En la XP, el alcance se determina escuchando a 
los clientes y poniéndolos a redactar sus relatos. A continuación se examinan estos relatos 
para calcular cuánto puede hacerse en un tiempo específico para satisfacer al cliente. Los 
relatos deben ser breves y fáciles de comprender. En el capítulo 6 veremos con más detalle 
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los relatos, pero a continuación presentamos un sencillo ejemplo que muestra cuatro relatos 
de un sistema de vuelos en línea. Cada relato se muestra en negritas: 

Mostrar vuelos alternativos. 

Prepare una lista de los cinco vuelos más económicos. 

Ofrecer alternativas más económicas. 

Sugiera al cliente que viaje en otros días, resen’e los fines de semana, aproveche promocio¬ 
nes especiales o use aeropuertos alternos. 

Compre un boleto. 

Permítale al cliente comprar directamente un boleto a través de tarjeta de crédito (verifique 
la validez). 

Permítale al cliente escoger su asiento. 

Dirija al cliente a una vista del avión y pídale que seleccione un asiento. 

Seria aún mejor si el analista pudiera determinar el tiempo y el dinero necesarios para 
satisfacer cada uno de estos relatos y establecer también su nivel de calidad. Es obvio que 
este sistema no debe sacrificar la calidad, porque las compras con tarjeta de crédito podrían 
ser improcedentes o los clientes podrían presentarse en el aeropuerto y enfrentarse al pro¬ 
blema de que su reservación no está registrada. 

Una vez más la XP permite medidas extremas, así que, con el fin de mantener la ca¬ 
lidad, manejar el costo y terminar el proyecto a tiempo, el analista de XP podría recurrir 
a ajustar el alcance del proyecto. Esto tiene que hacerse de común acuerdo con el cliente 
para posponer uno o más requerimientos hasta la siguiente versión del software. Por 
ejemplo, quizá pueda aplazarse la funcionalidad de permitir a los clientes escoger sus pro¬ 
pios asientos. 

En resumen, el analista de XP puede controlar cualquiera de las cuatro variables de re¬ 
cursos de tiempo, costo, calidad y alcance. La XP requiere medidas extremas y pone mucho 
énfasis en terminar un proyecto a tiempo. Para lograr esta meta se deben hacer sacrificios y 
el analista de XP se dará cuenta de que los intercambios que enfrentará implican decisiones 
difíciles. 

PRÁCTICAS Y ROLES ESENCIALES DE LA PROGRAMACIÓN EXTREMA 

Ahora que hemos visto cómo podemos administrar proyectos de sistemas utilizando los 
conceptos de la programación extrema, nos enfocaremos en los métodos para desarrollar y 
planear sistemas de XP. En esta sección nos adentraremos en las prácticas esenciales de XP 
que lo hacen diferente del enfoque SDLC y otras metodologías de desarrollo. Después ex¬ 
plicaremos con detalle algunos de los roles que desempeñan los participantes en el desarro¬ 
llo de XP. Posteriormente describiremos cómo se planean los proyectos de XP mediante un 
concepto conocido como el juego de la planeación. Finalmente, veremos algunos riesgos y 
temores del desarrollo de sistemas y cómo enfrenta la XP estos riesgos. 

Cuatro prácticas esenciales de XP Una de las formas de administrar un proyecto para ter¬ 
minarlo a tiempo consiste en equilibrar los recursos. Sin embargo, la mejor manera de admi¬ 
nistrar es desarrollar prácticas que produzcan resultados excelentes. El movimiento de la 
programación extrema ha desarrollado un conjunto de prácticas esenciales que han cambia¬ 
do la manera de desarrollar sistemas. A continuación mencionamos cuatro prácticas extre¬ 
mas. Como podrá ver, son extremas en comparación con lo que hemos visto hasta aquí en 
cuanto a la administración de proyectos. En la figura 3.16 se ilustran estas cuatro prácticas 
esenciales. 

1. Liberación limitada. Para que el desarrollo de XP tenga éxito, los productos deben libe¬ 
rarse con rapidez. Esto significa que aun cuando los programadores no puedan imple- 
mentar todas las características en una sola pieza de software, la versión debe liberarse 
de acuerdo con lo programado. Sí, esto es extremo, pero los clientes estarán contentos 
porque tendrán un producto para usar. Más tarde puede hacerse cualquier mejora. Es- 
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ta práctica se usa ampliamente en el desarrollo de software para PCs y es aún más 
común en el mundo de las computadoras portátiles. En Estados Unidos, incluso el soft¬ 
ware fiscal se libera en los inicios de la época de pago de impuestos antes de que estén 
terminadas todas las leyes fiscales (y los formularios]. Los desarrolladores de software 
fiscal están conscientes de que el cliente necesita el producto lo más pronto posible. 

2. Semana de trabajo de 40 horas. El modelo de Silicon Valley para el desarrollo de soft¬ 
ware propició que los programadores vivieran en la oficina y trabajaran presionados por 
las fechas. No ocurre así con la programación extrema. Los equipos de desarrollo de XP 
fomentan una práctica cultural en la que el equipo trabaja de manera intensa durante 
una semana típica de 40 horas. Esta práctica esencial de la programación extrema tiene 
como propósito motivar a los miembros del equipo a que laboren intensamente en el 
lugar de trabajo, y que tomen un periodo de descanso para que cuando vuelven al traba¬ 
jo estén relajados, menos presionados, con capacidad de detectar los problemas y menos 
proclives a cometer errores costosos y omisiones debido a un desempeño ineficiente o 
a la apatía. 

3. Cliente en el sitio. La mayoría de los desarrolladores de sistemas argumentan que el 
cliente es vital para el éxito del sistema, pero terminan reuniéndose sólo una o dos ve¬ 
ces con el cliente para determinar los requerimientos del sistema. La práctica esencial 
del cliente en el sitio llega al extremo al insistir en que un experto en el negocio debe 
trabajar en el sitio durante todo el proceso de desarrollo. Esta persona toma parte acti¬ 
va en el proceso, pues escribe los relatos del usuario (véase el capítulo 6), se comunica 
con los miembros del equipo y ayuda a establecer prioridades. 

4. Programación en parejas. ¿Extremo? Definitivamente. Estamos bastante familiarizados 
con el concepto de equipos de analistas de sistemas; ¿por qué no tener equipos de pro¬ 
gramadores? No, un programador no mira por encima del hombro de los demás para 
ver si se cometen errores. Más bien, la programación en parejas significa que dos pro¬ 
gramadores que eligen trabajar juntos hacen la programación, ejecutan las pruebas y 
conversan acerca de formas de hacer eficiente y eficazmente el trabajo. Al trabajar con 
otro programador puede clarificar su forma de pensar. La programación en parejas aho¬ 
rra tiempo, reduce la negligenciá, estimula la creatividad y es una manera divertida de 
programar. 

Roles de las personas Hay muchos roles que las personas deben desempeñar en los proyec¬ 
tos de desarrollo de XP, e incluso se requerirá que algunas personas desempeñen múltiples 
roles durante el esfuerzo. Los siete roles son: programador, cliente, probador, rastreador, 
entrenador, consultor y (medio en broma) "gran jefe". Los siete roles se muestran en la figu¬ 
ras.17. 

Con frecuencia, a los programadores se les considera como el corazón del desarrollo 
de XP. Sin embargo, las fortalezas de los programadores de XP son bastante diferentes a las de 
otros programadores, porque a los primeros se les exige ante todo que sean excelentes co- 
municadores. Las habilidades de comunicación entran enjuego tan pronto como empieza 
un esfuerzo de desarrollo, porque la XP exige el trabajo en parejas de programación, en el 
cual cada programador codifica, aunque suele haber un programador principiante y uno ex- 
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perimentado en una tarea determinada. Como programador, usted también necesita contar 
con excelentes habilidades técnicas para programar, refactorizar y realizar pruebas unitarias 
al código que escriba. Además, necesita una buena disposición para abordar con sencillez los 
problemas más difíciles, aprender de otros, compartir el código y el diseño, y tener el valor 
para superar cualquier temor de incompetencia o fracaso al enfrentar nuevos problemas. 

El siguiente rol que describiremos es el de cliente. La mejor forma de describirlo es que 
el cliente debe adoptar nuevas cualidades, algunas de ellas muy similares a las de un progra¬ 
mador, conservando al mismo tiempo la esencia de lo que necesita el sistema. El cliente más 
adecuado para el equipo de XP es alguien que será usuario del sistema y que conoce la fun¬ 
cionalidad de negocios que éste requiere. Con esto en mente, el cliente debe aprender a es¬ 
cribir relatos de usuario, aprender a escribir pruebas funcionales para las aplicaciones que 
generen los programadores, y tomar decisiones acertadas sobre las características esenciales 
del sistema e incluso sobre ajustes a la programación del proyecto y a las fechas de entrega. 
Los clientes también necesitan demostrar que tienen valor para enfrentar problemas graves 
referentes a la programación del proyecto al funcionamiento del sistema. 

Un tercer rol es el de probador de un equipo de desarrollo de XP. A los programadores 
se les pide que realicen pruebas unitarias y de funcionamiento del nuevo código que se ha¬ 
ya escrito. El programador también necesita comunicarse con el cliente sobre las pruebas 
de funcionamiento, realizar pruebas con regularidad, dar mantenimiento a las herramien¬ 
tas de prueba y elaborar informes precisos acerca de los resultados de las pruebas. 

Otro rol en el equipo de desarrollo de XP es el de rastreador. Este da seguimiento al 
progreso general del grupo calculando el tiempo que toman sus tareas y el progreso general 
hacia sus metas. El rastreador realiza estimaciones de tiempo, pero también da retroalimen- 
tación acerca de las estimaciones del equipo. ¿Eran demasiado bajas o demasiado altas? ¿En 
qué porcentaje fueron incorrectas? En el rol de rastreador usted podrá ofrecer esta valiosa 
información al equipo, con el fin de que mejoren la precisión de sus estimaciones. Los ras¬ 
treadores también fungen como memoria del equipo, al dar seguimiento a los resultados de 
todas las pruebas de funcionamiento. Asimismo, registran los defectos reportados y el nom¬ 
bre del programador a cargo del manejo de cada defecto. Además, dan seguimiento a los ca¬ 
sos de prueba agregados para resolver los defectos. 

A continuación consideraremos el rol de entrenador, quien con frecuencia es una mano 
invisible que guía el proceso general. Dado que una de las características distintivas del de¬ 
sarrollo de XP es que cada persona acepta la responsabilidad por sus acciones, un entrena¬ 
dor podría parecer innecesario. Sin embargo, los entrenadores son muy importantes. Por 
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ejemplo, ellos conservan la calma cuando todo el equipo está asustado. Ellos moldean las 
situaciones de manera indirecta (la mayor parte del tiempo], y sólo de vez en cuando nece¬ 
sitan retirar con firmeza el mando a un programador errático, volver a encarrilarlo y devol¬ 
verle las riendas otra vez. Un buen entrenador recuerda constantemente a los miembros del 
equipo la manera en que se comprometieron a actuar en un principio. Un entrenador podría 
recordarle a un programador: "Estuviste de acuerdo en compartir la propiedad del código", 
o "Prometiste tomar primero el enfoque más simple". Los entrenadores procuran resaltar las 
mejores cualidades de todos los demás miembros del equipo y mantenerse ellos en segundo 
plano la mayor parte del tiempo. 

El próximo rol que examinaremos es el de consultor. El rol de un experto en consulto- 
ría técnica es muy singular. Si usted se está desempeñando como consultor de un equipo, 
sus miembros le pedirán que resuelva los problemas junto con ellos, fastidiándolo a cada 
momento y cuestionando cualquier suposición que usted haga. Lo que los equipos de desa¬ 
rrollo de XP esperan de un consultor es que éste les enseñe a resolver sus propios proble¬ 
mas. A medida que aprendan de usted, renacerá en ellos la confianza, y cuando usted deje 
al equipo tal vez ellos utilicen o desechen la solución que les haya presentado, pero no se 
preocupe, esto es común. 

El último rol que consideraremos para el equipo de desarrollo de XP es el de gran jefe 
o líder. El equipo espera que el gran jefe confíe en ellos, demuestre disposición para apegar¬ 
se a los valores y principios a los que ellos se apeguen, y que tenga la capacidad de señalar 
un error si el equipo se desvía del camino. El equipo requerirá mantenerse en comunicación 
con usted (incluso los pequeños cambios al diseño o las desviaciones de otras metas). Su ta¬ 
rea es conseguir que la comunicación fluya sin convertirse en una ola de rumores. Ante todo, 
usted no desea ser un obstáculo para cualquier cosa razonable que el equipo intente reali¬ 
zar. Este es un rol que exige una total convicción en el enfoque de XP y de que si todos en 
el equipo se apegan a sus valores y principios básicos, es muy probable que lograrán algo 
que valga la pena. 


El juego de la planeación Todo el proceso de la planeación se ha representado con la idea 
de un juego de la planeación (Beck, 2000, p. 86). El juego de la planeación plantea reglas que 
pueden ayudar a establecer las relaciones del equipo de desarrollo de XP con sus clientes de 
negocios. A pesar de que las reglas le dan una idea sobre la manera en que usted desea que 
cada una de las partes actúe durante el desarrollo, no sustituyen a una relación. Son una ba¬ 
se para construir y mantener una relación. 

Aquí usamos la metáfora de unjuego. Por lo tanto, hablamos en términos de la meta del 
juego, la estrategia a seguir, las piezas a mover y los jugadores involucrados. La meta del jue¬ 
go es maximizar el valor del sistema producido por el equipo de XP. Para averiguar el valor, 
tiene que deducir los costos del desarrollo, así como el tiempo, gastos e incertidumbre asu¬ 
midos para que el proyecto de desarrollo pueda avanzar. 

La estrategia seguida por el equipo de desarrollo de XP siempre está encaminada a li¬ 
mitar la incertidumbre (minimizar el riesgo). Para lograrlo, diseñan la solución más simple 
posible, ponen el sistema en producción lo más pronto que pueden, piden retro alimenta¬ 
ción al cliente de negocios sobre lo que está funcionando y adaptan el diseño partiendo de 
este punto. 

En el juego de la planeación, las tarjetas de relatos se convierten en las piezas que des¬ 
criben brevemente las tareas, ofrecen notas y proporcionan un área para dar seguimiento a 
las tareas. 

Hay dos jugadores principales en el juego de la planeación: el equipo de desarrollo y el 
cliente de negocios. No siempre es sencillo decidir qué grupo de negocios en particular será 
el cliente de negocios, porque el proceso de XP es un rol extremadamente demandante pa¬ 
ra el cliente. Los clientes deciden lo que el equipo de desarrollo debe atacar primero. Sus de¬ 
cisiones establecerán las prioridades y comprobarán las funcionalidades a lo largo del proceso. 


Manejo de los riesgos de un proyecto en XP Hasta el momento, nuestra descripción de la 
programación extrema se ha centrado en la planeación y en la manera de ajustar nuestros 
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recursos conforme se requiera. No obstante, es importante tomar en cuenta que los proyec¬ 
tos de sistemas pueden tener, y de hecho tienen, graves problemas. Los proyectos que se de¬ 
sarrollan usando la programación extrema no son inmunes a esta clase de problemas. Para 
ilustrar los problemas que podrían surgir en un proyecto, el analista de sistemas se podría 
recurrir a un diagrama de pescado (también conocido como diagrama de causa-efecto o dia¬ 
grama de Ishikawa). Si observa la figura 3.18, verá que se denomina diagrama de pescado 
porque se parece al esqueleto de un pez. 


El valor de los diagramas de pescado es que listan de manera sistemática todos los pro¬ 
blemas que se pueden suscitar. En el caso de XP, es útil organizar el diagrama de pescado 
listando todas las variables de control de recursos en la parte superior y todas las actividades 
en la parte inferior. Algunos problemas como el recorrido de las fechas programadas podrían 
ser obvios, pero otros como la ampliación del alcance (el deseo de agregar características 
después de que el analista oye nuevos relatos] o el desarrollo de características de menor va¬ 
lor no son tan obvios. 


Muchos de estos problemas se pueden evitar utilizando la filosofía de la programación 
extrema. La XP tiene ciclos de liberación bastante cortos, por lo que los clientes tienen una 
amplia oportunidad de influir en el diseño y de ayudar a incrementar la calidad. Los recorri¬ 
dos de las fechas programadas se mantienen al mínimo. La programación en parejas ayuda a 
mantener la calidad, reducir la rotación de personal, minimizar la ampliación del alcance y 
limitar al mínimo los defectos. 

Al escuchar y responder a los relatos escritos y hablados de los clientes se minimizan 
los casos en que se entiende mal un negocio. Al contar con un cliente en el sitio se reduce la 
probabilidad de que un proyecto sea cancelado o que un negocio se modifique sustancial¬ 
mente sin que se entere el equipo de XP. La programación extrema reduce de muchas ma¬ 
neras los problemas potenciales. En resumen, es importante identificar los lugares donde 
pueden ocurrir problemas, pero sin duda no es de mucha ayuda tenerles miedo. 

Muchos otros enfoques de desarrollo le imputarían al analista los problemas derivados 
de la falta de comunicación, de la tendencia hacia la complejidad, o del miedo. Sin embar¬ 
go, la XP enfrenta estas situaciones poniendo énfasis en que analistas y clientes compartan 
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valores que les permitan evitar estos problemas. En el capítulo 6 se dan más detalles acerca 
de estos valores compartidos. 

EL PROCESO DE DESARROLLO PARA UN PROYECTO DE XP 

Hay actividades y comportamientos que moldean la manera en que los miembros de un 
equipo de desarrollo y los clientes actúan durante el desarrollo de un proyecto de XP. Inte¬ 
ractivo e incremental son dos conceptos que caracterizan a un proyecto realizado con un 
enfoque de XP. Al examinar la figura 3.19, podrá ver que hay cinco etapas: exploración, 
planeación, iteraciones a la primera versión, puesta en producción y mantenimiento. Obser¬ 
ve que las tres flechas que hacen un ciclo hacia la caja de las "Iteraciones" simbolizan los 
cambios increméntales generados a través de las pruebas y retroalimentaciones repetidas 
que a futuro dan como resultado un sistema estable pero en evolución. Observe también que 
hay muchas flechas que hacen un ciclo de retroalimentación en la etapa de puesta en pro¬ 
ducción. Esto significa que el ritmo de las iteraciones se incrementa después de la liberación 
de un producto. La flecha gruesa abandona la etapa de mantenimiento y regresa a la etapa de 
planeación, generando un ciclo continuo de retroalimentación entre los clientes y el equipo 
de desarrollo cada vez que éstos acuerdan realizar modificaciones al sistema en evolución. 

Durante la etapa de exploración, usted examinará su entorno, sosteniendo su convic¬ 
ción de que el problema puede y debe enfrentarse mediante programación extrema, con¬ 
formará el equipo y valorará las habilidades de los miembros del mismo. Esta etapa durará 
desde unas cuantas semanas [si usted conoce de antemano a los miembros del equipo y la 
tecnología) hasta algunos meses (si todo es nuevo). También se ocupará de examinar las tec¬ 
nologías potenciales que requerirá para construir el nuevo sistema. Durante esta etapa debe 
practicar el cálculo de tiempo que tomarán diversas tareas. Los clientes también experi¬ 
mentarán con la escritura de relatos del usuario. El objetivo es lograr que el cliente refine lo 
suficiente un relato para que usted pueda calcular con eficiencia la cantidad de tiempo que 
tomará construir la solución en el sistema que está planeando. Lo importante en esta etapa 
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es adoptar una actitud desenvuelta y de curiosidad hacia el entorno de trabajo, sus proble¬ 
mas, tecnologías y gente. 

La planeación es la siguiente etapa del proceso de desarrollo de XP. En contraste con la 
primera etapa, la planeación podría tomar sólo algunos días. En esta etapa usted y sus 
clientes establecen una fecha de común acuerdo, que puede ir de dos meses a medio año a 
partir de la fecha actual, para la entrega de soluciones a los problemas de negocios más ur¬ 
gentes de los clientes [usted se enfocará en el conjunto de relatos más pequeño e importan¬ 
te). Si las actividades que realizó en la etapa de exploración fueron suficientes, esta etapa 
debe ser muy corta. 

La tercera etapa en el proceso de desarrollo de XP consta de iteraciones a la primera 
versión. Por lo general, estas iteraciones (ciclos de pruebas, retroalimentación y cambios) 
duran aproximadamente tres semanas. Tendrá que bosquejar toda la arquitectura del siste¬ 
ma, aunque sólo sea un diseño preliminar. Una meta es realizar pruebas de funcionamiento 
escritas por el cliente al final de cada iteración. Durante la etapa de iteraciones también 
debe preguntarse si es necesario modificar las fechas programadas o si está trabajando con 
muchos relatos. Realice pequeñas ceremonias con los clientes y los desarrolladores al termi¬ 
nar con éxito cada iteración. Celebre siempre sus avances, aun cuando sean pequeños, pues¬ 
to que esto es parte de la cultura de motivar a todos para que pongan todo su entusiasmo en 
el proyecto. 

Al finalizar todas las iteraciones, el sistema está listo para pasar a la siguiente etapa: la 
puesta en producción. Durante esta etapa se realizan diversas actividades. El ciclo de retro- 
alimentación se acelera, de tal manera que en lugar de recibir retroalimentación para una 
iteración cada tres semanas, las revisiones del software se realizan en una semana. Se po¬ 
drían implantar sesiones informativas diarias para que todo el mundo se entere de lo que 
están haciendo los demás. El producto se libera en esta etapa, aunque se puede mejorar in¬ 
corporándole otras características. La puesta en producción de un sistema es un suceso emo¬ 
cionante. Dése tiempo para celebrar con sus compañeros de equipo y registre el suceso. Una 
de las consignas del enfoque de la XP, con el cual estamos totalmente de acuerdo, es que 
[el desarrollo de sistemas debe ser divertido! 

La última etapa que consideramos es el mantenimiento. Este se ha descrito como "el es¬ 
tado normal de un proyecto de XP" (Beck, 2000, p. 135). Una vez que se ha liberado el 
sistema, es necesario mantenerlo funcionando sin problemas. Se pueden agregar nuevas ca¬ 
racterísticas, se pueden tomar en cuenta las sugerencias más arriesgadas del cliente y se pue¬ 
den cambiar o incorporar nuevos miembros del equipo. La actitud que debe tomar en este 
punto del proceso de desarrollo es más conservadora que en cualquier otro momento. Su rol 
ahora es el de "mantener viva la llama" más que el de desenvoltura que experimentó duran¬ 
te la etapa de exploración. 

La filosofía que anima a la programación extrema es más que sólo planear y administrar 
un proyecto de sistemas con métodos extremos. Tiene como base valores y principios. 



RESUMEN 

Los cinco aspectos fundamentales de un proyecto que el analista de sistemas debe dominar 
son: (1) la iniciación de proyectos, (2) la determinación de la viabilidad de un proyecto, (3) 
la planeación y el control de actividades, (4) la programación de proyectos y (5) la adminis¬ 
tración de los miembros del equipo de análisis de sistemas. Los proyectos pueden ser solici¬ 
tados por diversas personas de la organización o por los mismos analistas de sistemas. 

La selección de un proyecto es una decisión difícil, ya que se solicitarán más proyectos 
de los que se pueden realizar. Cinco criterios importantes para la selección de proyectos son: 
(1) que el proyecto solicitado tenga el respaldo de los directivos de la organización, (2) que 
cuente con un periodo adecuado de compromiso para la terminación del proyecto, (3) 
que impulse a la organización hacia la consecución de sus metas, (4) que sea factible y 
(5) que tenga la importancia suficiente para darle mayor prioridad que a otros proyectos. 

FUNDAMENTOS DEL ANÁLISIS DE SISTEMAS_ 





EXPERIENCIA CON HYPERGASE® 


"Espero que todas las personas que haya encontrado en MRE le hayan dado un buen trato. 
A continuación doy un breve repaso a algunas de las opciones que tiene para acceder ¡i 
nuestra organización a través de HyperCase. En la recepción de MRE se encuentran los 
vínculos clave al resto de nuestra organización. Tal vez ya los haya descubierto por sí mismo, 
pero deseo describírselos en este momento, porque no quisiera concentrarme demasiado en 
el resto de los problemas de nuestra organización y olvidar mencionarlos más tarde." 

"El teléfono en el escritorio de la recepcionista tiene instrucciones relacionadas con la 
forma de contestarlo en el resto de la organización. Usted cuenta con mi autorización para 
responder el teléfono si éste suena y nadie más lo contesta." 

"La entrada sin puerta que ve, es un vínculo a la siguiente habitación, que nosotros lla¬ 
mamos el Atrio Oriental (East Atrium]. Tal vez se haya percatado de que todas las entradás 
sin puerta son vínculos hacia habitaciones contiguas. Observe el mapa del edificio en una de 
las paredes de la recepción. Usted puede pasear libremente por las áreas públicas como la 
taberna, pero como sabe, algún empleado debe acompañarlo para entrar en una oficina pri¬ 
vada. No puede entrar solo ahí," 

"Tal vez ya haya visto los dos documentos y la computadora en la pequeña mesa de la 
recepción. El pequeño es el directorio telefónico interno de MRE Tan sólo haga clic en el 
nombre de un empleado, y si éste se encuentra disponible, le concederá una entrevista y le 
dará un paseo por la oficina. Dejo a su iniciativa averiguar de qué trata el otro documento." 

"La computadora en la mesa está encendida y muestra la piágina Web inicial de MRE. 
Debería usted dar un vistazo a la página corporativa y visitar todos lós vínculos. Esta página 
contiene la historia de nuestra compañía y de la gente que labora aquí. Estamos muy orgu¬ 
llosos de ella y hemos tenido retro alimentación positiva sobre ella de nuestros visitantes." 




La recepción se parece a la de cualquier corporación típica. Mientras usted esté en esta 
pantalla de HyperCase, consulte el directorio si desea visitar a alguien. 


(continúa) 
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"Si ha teñido lá oportunidad de entrevistar a alguien y de conocer el funcionamiento de 
nuestra compañía, estoy seguro de que ya se enteró de algunas de nuestras políticas. Sin em¬ 
bargo, también estamos preocupados por asuntos más técnicos, como en qué consiste la via¬ 
bilidad de un proyecto de capacitación." 

PREGUNTAS DE HYPERCASE 

1. ¿Qué criterios emplea la Unidad de Capacitación para determinar la viabilidad de un 
nuevo proyecto? Menciónelos. 

2. Haga una lista de los cambios p modificaciones a estos criterios que usted recomendaría. 

3. Snowden Evans le ha pedido a usted que le ayude a preparar una propuesta para un 
nuevo sistema de seguimiento de proyectos para la Unidad de Capacitación. Explique 
brevemente la viabilidad técnica, económica y operativa de cada alternativa para un sis¬ 
tema de seguimiento de proyectos propuesto para la Unidad de Capacitación. 

4. ¿Cuál opción recomendaría usted? Utilice evidencias que haya encontrado en Hyper- 
Case para respaldar su decisión. 


Si un proyecto solicitado satisface estos criterios, se puede emprender un estudio de 
viabilidad de sus capacidades operativas, técnicas y económicas. A través del estudio de via¬ 
bilidad, los analistas de sistemas recopilan datos que facilitan a los directivos de la organiza¬ 
ción la decisión de realizar un estudio de sistemas completo. La planeación de proyectos in¬ 
cluye la estimación del tiempo requerido por cada una de las actividades del analista, y 
programarlas y acelerarlas si es necesario para garantizar que un proyecto se terminará a 
tiempo. La gráfica de Gantt, que representa las actividades como barras, es una de las técnicas 
de que disponen los analistas de sistemas para programar tareas. 

Otra técnica, conocida como PERT (de Técnicas de Evaluación y Revisión de Progra¬ 
mas), representa las actividades como flechas en una red. Los diagramas PERT, ayudan al 
analista a determinar la ruta critica y el tiempo de holgura, que es la información necesaria 
para controlar con eficiencia un proyecto. El enfoque de punto de entrega (timeboxing) es¬ 
tablece una fecha de vencimiento absoluta para el proyecto, y todo lo que se haya termina¬ 
do para esa fecha debe implementarse. 

Ya es una realidad la programación de proyectos por computadora utilizando PCs. Ade¬ 
más, los analistas pueden utilizar administradores de información personal para las tareas de 
planeación, para crear depósitos de números telefónicos y de fax, o incluso para arrancar 
otros programas. La mayoría de los PIMs se pueden sincronizar con PIMs de computadoras 
Palm y otros dispositivos portátiles, facilitando una excelente portabilidad. 

Una vez que un proyecto ha sido calificado como viable, el analista de sistemas debe 
administrar a los miembros del equipo y sus actividades, tiempo y recursos. Esta administra¬ 
ción se realiza por medio de la comunicación con los miembros del equipo. Los equipos 
buscan constantemente un equilibrio entre dedicarse a realizar sus tareas y mantener buenas 
relaciones en el equipo. Es necesario solucionar las tensiones que surjan al intentar conse¬ 
guir este equilibrio. Con frecuencia un equipo tendrá dos líderes, un líder de tareas y un lí¬ 
der socioemocional. Los miembros deben evaluar periódicamente las normas del equipo 
para garantizar que éstas sean funcionales en vez de disfuncionales para la consecución de 
las metas del equipo. 

La administración de proyectos de comercio electrónico es semejante en varios aspectos 
a la administración de proyectos tradicionales de sistemas de información, pero hay cuatro 
aspectos en los cuales difieren significativamente. El primero es que los datos que usted ten¬ 
drá que coordinar están dispersos por toda la organización (lo cual tiene implicaciones po¬ 
líticas); otro es que los miembros especializados del equipo se tienen que reclutar de todas 
las áreas de la organización (aquí también podrían verse implicadas las políticas de la orga¬ 
nización); un tercer aspecto es que el gerente de un proyecto de comercio electrónico debe 
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resaltar la integración estratégica del comercio electrónico con todos los sistemas de la orga¬ 
nización, y el cuarto aspecto es que al establecer un sitio de comercio electrónico primero 
se deben abordar las cuestiones de seguridad. 

Es importante que el equipo de análisis de sistemas fije metas de productividad razona¬ 
bles para las salidas tangibles y las actividades de los procesos. Fechas límites irreales fijadas 
por los directivos, la incorporación innecesaria de personal a un proyecto en un intento por 
cumplir fechas límite irreales, y la prohibición a los equipos de desarroUadores para que 
recurran a la ayuda de expertos externos, fueron argumentos que los programadores esgri¬ 
mieron como razones del fracaso de proyectos. Por lo general, el fracaso de un proyecto se 
puede evitar analizando las razones por las cuales fue solicitado, así como los motivos de su 
equipo para recomendar o evitar un proyecto en particular. 

La programación extrema, o XP, es una alternativa al SDLC. La metodología de desa¬ 
rrollo de XP adopta técnicas extremas útiles para la administración de proyectos y para ter¬ 
minarlos a tiempo. En la XP, los recursos de que dispone un analista deben equilibrarse con 
las actividades desempeñadas. 

La XP difiere de otros procesos de desarrollo de proyectos, pues utiliza prácticas de li¬ 
beración a corto plazo, semana de trabajo de 40 horas, un cliente en el sitio y programación 
en parejas. Los siete roles importantes en el proceso de desarrollo de XP son el de progra¬ 
mador, cliente, probador, rastreador, entrenador, consultor y gran jefe. 

En la XP, la planeación se lleva a cabo mediante una técnica conocida como el juego de 
la planeación, que proporciona reglas que el equipo de desarrollo de XP debe seguir al esta¬ 
blecer sus relaciones con un cliente. Las cinco amplias etapas en el proceso de desarrollo de 
XP son la exploración, la planeación, las iteraciones a la primera versión, la puesta en pro¬ 
ducción y el mantenimiento. 


PALABRAS Y FRASES CLAVE 


administración de proyectos de 
comercio electrónico 
administradores de información 
personal (PIMs) 
cliente en el sitio 

cuadrícula de impacto de la viabilidad 
(CIV) 

diagrama PERT 
el juego de la planeación 
etapa de exploración 

etapa de iteraciones a la primera versión 

etapa de mantenimiento 

etapa de planeación 

etapa de puesta en producción 

gráfica de Gantt 

liberación a corto plazo 


líder de tareas 
líder socioemocional 
metas de productividad 
motivación del equipo 
normas del equipo 
proceso del equipo 
programación de proyectos por 
computadora 

programación en parejas . 
programación extrema (XP) 
punto de entrega (timeboxing) 
ruta crítica 

semana de trabajo de 40 horas 
viabilidad económica 
viabilidad operativa 
viabilidad técnica 


PREGUNTAS DE REPASO 

1. ¿Cuáles son los cinco aspectos fundamentales de un proyecto? 

2. Mencione tres formas de detectar problemas u oportunidades que podrían requerir una 
solución de sistemas. 

3. Enumere los cinco criterios para la selección de proyectos de sistemas. 

4. Examine la cuadrícula de impacto de la viabilidad que se muestra en la figura 3.3. 
Mencione los objetivos corporativos que reciben una influencia positiva de los sistemas 
de comercio electrónico. 

5. Defina qué es la viabilidad técnica. 

6. Defina qué es la viabilidad económica. 

7. Defina qué es la viabilidad operativa. 
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8. ¿En qué situación es más apropiada una gráfica de Gantt tridimensional que una unidi¬ 
mensional? 

9. ¿Cuándo es útil para un proyecto de sistemas el uso de un diagrama PERT? 

10. Mencione tres ventajas de un diagrama PERT sobre una gráfica de Gantt para la pro¬ 
gramación de proyectos de sistemas. 

11. Defina el concepto de ruta crítica. 

12. Defina en qué consiste la técnica de punto de entrega (timeboxing). 

13. Mencione las funciones disponibles en los paquetes comerciales de software para pro¬ 
gramación de proyectos por computadora. 

14. Mencione las funciones más comunes de un paquete de software de administración de 
información personal (PIM). 

15. Mencione los dos tipos de líderes de un equipo. 

16. ¿Qué significa que una norma del equipo sea disfuncional? 

17. ¿Qué es un proceso del equipo? 

18. Mencione tres razones por las cuales la fijación de metas motiva a los miembros de un 
equipo de análisis de sistemas. 

19. ¿Cuáles son los cuatro aspectos en que difieren la administración de proyectos de co¬ 
mercio electrónico y la administración de proyectos tradicionales? 

20. Mencione tres razones que argumenten los programadores para el fracaso de proyectos. 

21. ¿Por qué es tan extrema la programación extrema? 

22. Mencione las cuatro viables de control de recursos que utiliza la XP. 

23. Mencione las cuatro actividades relacionadas con la XP. 

24. Describa cómo se utilizan las variables de control para equilibrar las actividades en un 
proyecto de XP exitoso. 

25. ¿Cuáles son las cuatro prácticas esenciales del enfoque de desarrollo de XP que lo dis¬ 
tinguen de otras metodologías de desarrollo? 

26. ¿Cuáles son los siete roles que se deben desempeñar durante el proceso de desarrollo 
deXP? 

27. ¿Cuál es el significado de la frase "el juego de la planeación"? 

28. ¿Cuáles son las etapas del proceso de desarrollo de XP? 


PROBLEMAS 

1. Dressman's Chocolates, localizada en San Luis, Missouri, elabora una variedad de dul¬ 
ces de chocolate. La compañía cuenta con seis tiendas en la ciudad, cinco tiendas en los 
principales aeropuertos metropolitanos y una pequeña sucursal de pedidos por correo. 
Dressman's tiene un pequeño sistema de información computarizado que lleva el 
control del inventario en su planta, ayuda a programar la producción, entre otras acti¬ 
vidades, pero no está enlazado directamente con ninguna de sus tiendas detallistas. El 
sistema de pedidos por correo se maneja de manera manual. Recientemente, varias 
tiendas de Dressman's sufrieron una lluvia de quejas por parte de sus clientes que rea¬ 
lizan pedidos por correo, consistentes en que el dulce estaba echado a perder cuando 
lo recibían, que no se los entregaban en la fecha prometida, o que nunca les llegaba; la 
compañía también recibió varias cartas donde los clientes se quejaban de que el dulce 
que se vendía en los aeropuertos sabía rancio. Por último, algunos dependientes de las 
tiendas de la compañía informaron que algunos clientes querían saber si la compañía 
estaría dispuesta a vender un nuevo chocolate dietético, elaborado con edulcorante ar¬ 
tificial, sin azúcar. 

Usted había estado trabajando durante dos semanas con Dressman's en algunas 
modificaciones menores para su sistema de información de inventarios cuando escuchó 
por accidente que dos gerentes discutían estos sucesos. Mencione las posibles oportuni¬ 
dades o problemas derivados de estos sucesos que podrían ser adecuados para iniciar un 
proyecto de sistemas. 

2. ¿De dónde proviene la mayoría de los problemas de retroalimentación con los produc¬ 
tos de Dressman's que se mencionan en el problema 1? ¿Qué tan confiables son las 
fuentes? Dé su explicación en un párrafo. 
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3. Después de conocerlos mejor, usted se ha acercado a los directivos de Dressman's con 
algunas ideas sobre posibles mejores a los sistemas que podrían resolver algunos de los 
problemas u oportunidades que se mencionan en el problema 1. 

a. En dos párrafos, mencione sus recomendaciones de proyectos de sistemas. Haga to¬ 
das las suposiciones realistas que considere necesarias. 

b. De los problemas u oportunidades que se discuten en el problema 1, ¿hay alguno 
que sea inapropiado? Explique su respuesta. 

4. La empresa de consultoría en análisis de sistemas Flow Associates trabaja en un proyec¬ 
to de diseño de sistemas paraWind and Waves Surfing Gear, Inc. 

a. Utilizando los datos de la siguiente tabla, dibuje una gráfica de Gantt para ayudar 
a Flow Associates a organizar su proyecto de diseño. 

b. ¿En qué situación es apropiada una gráfica de Gantt? ¿Qué desventajas tiene? Ex¬ 
plique su respuesta en un párrafo. 


Descripción 

Tarea 

Debe 

seguirá 

Tiempo 

esperado (días) 

Dibujar el flujo de datos 

P 

Ninguno 

9 

Dibujar el árbol de decisiones 

Q 

P 

12 

Revisar el árbol 

R 

Q 

3 

Redactar el proyecto 

S 

R,Z 

7 

Organizar el diccionario de datos 

T 

P 

11 

Hacer prototipo de la salida 

X 

Ninguno 

8 

Revisar el prototipo de la salida 

Y 

X 

14 

Diseñar la base de datos 

Z 

T,Y 

5 


5. La figura 3.EX1 es un diagrama PERT creado por Flow Associates con base en los da¬ 
tos del problema 4. Mencione todas las rutas, y calcule e identifique la ruta crítica. 

6. Dos analistas recién egresados de la universidad se acaban de incorporar a su grupo de 
analistas de sistemas en la compañía Mega Phone, también de reciente creación. Cuando 
conversaron con usted acerca del grupo, mencionaron que algunas cosas les causaron 
extrañeza. Una de ellas es que los miembros del grupo parecen recurrir a dos líderes del 
grupo, Bill y Penny, no sólo a uno. 

Comentan que Bill parece bastante tranquilo, en tanto que Penny siempre está pla¬ 
neando y programando actividades. También dicen que "da la impresión de que todos 
saben qué hacer" cuando hay una reunión, aun cuando no se den instrucciones. Por úl¬ 
timo, resaltaron la apertura del grupo al abordar los problemas en cuanto surgen, en vez 
de permitir que las cosas se salgan de control. 

a. Como explicación para los nuevos miembros del equipo, identifique los tipos de lí¬ 
deres que son Bill y Penny, respectivamente. 

b. Explique la oración "da la impresión de que todos saben qué hacer". ¿Qué es lo 
que determina este comportamiento? 

c. ¿Qué concepto describe la apertura del grupo a la que se refieren los nuevos 
miembros del equipo? 

7. Prepare una lista de actividades para un agente de viajes en línea que desea establecer 
un sitio Web para que los clientes reserven vuelos, realicen compras directas y elijan sus 
propios asientos. Ahora suponga qué tiene usted poco tiempo. Describa algunas de 
sus opciones. Explique los intercambios que tendrá que realizar para entregar el sitio 
Web a tiempo. 
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PROYECTOS DE GRUPO 


1. Con los miembros de su grupo, explore un software de administración de proyectos co¬ 
mo Microsoft Project. ¿Con qué características cuenta? Trabaje con su grupo para des¬ 
cribirlas. Evalúen la utilidad del software para administrar un proyecto de un equipo de 
análisis y diseño de sistemas. En un párrafo, señale si el software que evalúa facilita la 
comunicación de los miembros del equipo y la administración de las actividades, tiem¬ 
po y recursos del equipo. Indique cuáles características en particular apoyan estos as¬ 
pectos de cualquier proyecto. Mencione si el software tiene deficiencias para satisfacer 
algunos de estos criterios. 

2. Asigne dentro de su grupo algunos de los roles que se adoptan en el desarrollo de pro¬ 
gramación extrema. Asegúrese de que una persona funja como cliente en el sitio y al 
menos dos sean programadores. Asigne otros roles, como el de entrenador, conforme lo 
considere adecuado. Reproduzca el caso de desarrollo de sistemas que se menciona en 
el problema 7, o haga que la persona que representa al cliente en el sitio elija un nego¬ 
cio de comercio electrónico que todos conozcan. Dé por hecho que el cliente desea in¬ 
corporar alguna funcionalidad a su sitio Web. Describa una situación que muestre lo 
que haría cada persona si este caso se abordara mediante la XP. Escriba en un párrafo qué 
restricciones enfrentaría cada persona para desempeñar su rol. 
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Cierto día. Chip entra a la oficina de Anna y le dice: "Pienso que el proyecto será bueno, aun 
cuando estamos invirtiendo muchas horas para empezarlo". 

Anna retira la vista de su pantalla y sonríe. "Me gusta lo que has hecho para organizar- 
nos", dice. "No me había dado cuenta de que Visible Analyst nos podía ayudar mucho con 
la administración del proyecto. He decidido hacer un diagrama PERT para la parte de reco¬ 
pilación de datos del proyecto. Esto nos puede ayudar a planear nuestro tiempo y a trabajar 
en equipo en actividades paralelas." 

"¿Puedo echar un vistazo al diagrama PERT?", pregunta Chip. 

Anna le muestra una pantalla con un diagrama PERT (véase la figura E3.1) y recalca: 
"Esto nos ayudará bastante. Es mucho más fácil que una planeación al azar". 

"Veo que tienes Recopilar Informes, Recopilar Registros y Formularios de Captura de 
Datos y Recopilar Documentos Cualitativos como tareas paralelas", comenta Chip mien¬ 
tras observa la pantalla. 

"Sí", contesta Anna. "Pensé que podríamos repartir el tiempo que toma la recopilación 
de información. También podemos dividir la tarea de analizar lo que vayamos recopilando." 

"He observado que asignaste bastantes días para entrevistar a los usuarios", comenta 
Chip. 

"Sí", contesta Anna. "Esta actividad también incluye la elaboración de preguntas, orde¬ 
narlas en secuencia, y otras tareas, como tomar apuntes del entorno de la oficina y analizar¬ 
los. También he tomado como estándar seis horas productivas por día." 



A Recopilar informes 
B Recopilar registros y formularios de 
captura de datos 

C Recopilar documentos cualitativos 
D Analizar Informes 
E Entender la cultura corporativa 


F Analizar registros y formularlos 
G Entrevistar usuarios 
H Aplicar cuestionarios 
I Resumir entrevistas 
J Resumir los resultados de las encuestas 
K Elaborar el prototipo del sistema 
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Diagrama PERTde la Central Pacific Umversity que se utiliza para recopilar información. 
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Anna mira su reloj. 'Ya es tarde. Creo que hemos tenido un gran progreso en la crea¬ 
ción de nuestro proyecto. Por hoy es suficiente. Recuerda, conseguí boletos para el juego 
de fútbol". 

Chip contesta: "No lo he olvidado. Déjame ir por mi chaqueta, y caminaremos juntos al 
estadio". 

Más tarde, al caminar por el campus. Chip dice: "Estoy emocionado. Es mi primer par¬ 
tido aquí en la CPU. ¿Cuál es la mascota del equipo?" 

"Una ardilla, desde luego", dice Anna. 

"¿Y los colores del equipo?", pregunta Chip mientras entran al estadio. 

"Azul y blanco", contesta Anna. 

"Oh, es por eso que todos gritan, [Vamos Gran Azul!", dice Chip, escuchando el rugido 
de la multitud. 

"Exactamente", dice Anna. 


EJERCICIOS 



E-l. Utilice Visible Analyst para ver el diagrama PERT de Recopilación de Información. 
E-2. Enumere todas las rutas y calcule y determine la ruta crítica para el diagrama PERT 
de Recopilación de Información. 

E-3. Utilice Visible Analyst para crear el diagrama PERT que se muestra en la figura E3.2. 
Esto representa las actividades involucradas en entrevistar a los usuarios y observar 
sus oficinas. 



G Registrar y analizar observaciones 
H Sintetizar las entrevistas a los gerentes 
I Sintetizar las entrevistas de operaciones 


uiagranid PcK rütr id UiTÍvtlIb'iiy PcTUfuTCef indi 'que'btf Uúfl¿cTeií ¡cf ñbts LfB entrevistas 
a los usuarios. 


Tw’ Los ejercicios precedidos por un ¡cono Web indican que hay material adicional en el sitio Web de este li¬ 
bro. Los estudiantes pueden descargar un proyecto de muestra de Visible Analyst y una base de datos de 
Microsoft Access para realizar los ejercicios. El software Visible Analyst debe adquirirse por separado, 
consulte el sitio Web de este libro. 
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E-4. Enumere todas las rutas y calcule y determine la ruta crítica para el diagrama PERT 
de entrevistas a los usuarios. 

E-5. Utilice Visible Analyst para crear un diagrama PERT que le sirva en la creación de 
prototipos del sistema. En la figura E3.3 se muestra la información de las actividades. 


Actividad 


Predecesor 


Duración 


A Determinar todas las pantallas 
e Informes del prototipo 
B Determinar el contenido de los Informes 
y ; las pantallas. 

C Crear prototipos de los Informes 
D Crear prototipos de las pantallas 
E Obtener retroallmentación sobre los prototipos 
de los informes 

F Obtenga retroallmentación sobre los prototipos 
do las pantallas 

G : Modificar los prototipos de los Informes 
H Modificar los prototipos de las pantallas 
I Obtener la aprobación final 


Ninguno 


Lista de actividades y tiempos de duración estimada para el proyecto de la CPU. 


DETERMINACDN DE LA VIABILIDAD Y ADMINISTRACION DE LAS ACTIVIDADES DE ANALISIS Y DISEÑO 














































































RECOPILACIÓN 
DE INFORMACIÓN: 
MÉTODOS INTERACTIVOS 




OBJETIVOS DE APRENDIZAJE 

Una vez que haya dominado el material de este capitulo, podrá: 

1. Reconocer el valor de los métodos Interactivos para la recopilación de Información. 

2. Formular preguntas para una entrevista con el fin de recabar los requerimientos de Información. 

3. ' Estructurar entrevistas de una forma significativa.: f s 4 , 

4. Entender el concepto de JAD y saber cuándo utilizarlo.. 

5. Escribir preguntas efectivas para las encuestas. 

6. Diseñar y aplicar cuestionarlos efectivos. 


:Hn> uvs métodos interactivas i/lave que usted puedo utilizar para.obtener los rói[uori- 
niientos ili* iníonnaeión do lor, minnhros de la oruani/ación, nichos métodos son Lis on- 
tr'Vvistjis, ol disi-jin lonjunlo di aplicaciones {ÍA\'ü.loint A¡>lúkmi<m Desigu)\ la realización 
de encuestas mediante cuestionarías. Aunque su implomentaáón os dílóronU-. estíw mó- 
tndos tiom-;n mucho en coim'ni. T.a base de /¡A propiedades if¡:é comparlen es hablar con. V 
escuchar a, las personas de la oi A am7ación por medid de una serie de pre A unu A formuladas 
CI.ndadqsamenu- 4 \ r '• 5:1 

(Jachi uno de los tres métodos interactivos para la recopilaron de información posee su 
propio proceso establecido para qué usted lo siga ai interactuar con los'usuarios. Si se siguen, 
estos enfoques sistemáticos ayudarán a garantizar el diseño y la impleméntacióñ apropiados 
de entrevistas, talleres JAD y cuestionarios, y apoyarán el análisis révelador de los datos re¬ 
sultantes. En un capítulo postérior se explicarári métodos discretos [muestréo, investigación 
y la observación del comportamiento y el entorno físico de los tomadores de;decisiones) 
que rto requieren el mismo grado de ihtcractividad éntre analistas y usuariós. Al ütilizar.mé- 
todos interactivos juntó con métodos discretos obtendrá un panorama más completo de los 
requerimientos de iiiforiTiacióri dé ÍSi'bfgíinización. • •. ; 


ENTREVISTAS 

Antes de que entreviste a alguien más. debe entrevistarse a sí mismo. .Necesita eonoccr 
sus prejuicios y cómo afectarán éstos sus pereepeioness Su educación, intelecto, formar 
eión, emociones y -mareó etico actúan como filtros poderosos de lo que va a oír en sús 
entrevistas . 1 . L. .v " ‘ 





























Necesita pensar detalladamente en las entrevistas antes de hacerlas. Visualice por qué 
las va a hacer, qué va a preguntar y qué es lo que a su juicio hará que esta entrevista tenga 
éxito. Asimismo, debe pensar cómo logrará que la entrevista sea satisfactoria para el indivi¬ 
duo al que entreviste. 

Una entrevista para recabar información es una conversación dirigida con un propósito 
específico que utiliza un formato de preguntas y respuestas. En la entrevista usted necesita 
obtener las opiniones de los entrevistados y su parecer acerca del estado actual del sistema, 
metas organizacionales y personales y procedimientos informales. 

Ante todo, busque las opiniones de la persona que entreviste. Las opiniones podrían ser 
más importantes y reveladoras que los hechos. Por ejemplo, imagine que le pregunta a la 
dueña de una tienda tradicional, quien recientemente estableció una tienda en línea, cuán¬ 
tos reembolsos de clientes procesa comúnmente mediante transacciones en la Web cada se¬ 
mana. Ella responde: "Entre 20 y 25 por semana". Cuando usted revisa las transacciones y 
descubre que el promedio es de tan sólo 10.5 por semana, podría llegar a la conclusión de 
que la propietaria está exagerando los hechos y el problema. 

En cambio, imagine que le pregunta a la propietaria cuáles son sus principales preocu¬ 
paciones y que ella responde: "En mi opinión, son demasiado altas las devoluciones de pro¬ 
ductos comprados a través de la Web". Al buscar opiniones más que hechos, usted descubre 
un problema clave que la propietaria desea solucionar. 

Además de las opiniones, usted debe tratar de captar los sentimientos de los entrevista¬ 
dos. Recuerde que éstos conocen la organización mucho mejor que usted. Al escuchar los 
sentimientos de los entrevistados, usted puede entender la cultura de la organización de una 
manera más completa. 

Las metas son información importante que se puede recabar de las entrevistas. Los he¬ 
chos que obtenga de los datos concretos y reales podrían explicar el desempeño pasado, pero 
las metas reflejan el futuro de la organización. Trate de averiguar lo más que pueda acerca 
de las metas de la organización por medio de las entrevistas. Este quizá sea el único método de 
recopilación de datos efectivo para determinar las metas de la organización. 

En la entrevista se entabla una relación con alguien que probablemente sea un extraño 
para usted. Necesita establecer confianza y entendimiento rápidamente, pero al mismo 
tiempo debe mantener el control de la entrevista. También necesita vender el sistema ofre¬ 
ciéndole la información necesaria a su entrevistado. Esto lo puede conseguir planificando la 
entrevista antes de realizarla, de tal manera que la conducción de la misma sea algo natural 
para usted. Afortunadamente, la realización eficaz de entrevistas es algo que puede apren¬ 
derse. Conforme practique, verá sus progresos. Más adelante en el capítulo explicaremos el 
diseño conjunto de aplicaciones (JAD), el cual puede ser una alternativa a las entrevistas 
uno a uno en ciertas situaciones. 


CINCO PASOS PARA PREPARAR UNA ENTREVISTA 

En la figura 4.1 se muestran los cinco pasos principales para preparar una entrevista. Estos 
pasos incluyen un rango de actividades que van desde recopilar antecedentes básicos hasta 
decidir a quién entrevistar. 

Leer los antecedentes Leer y entender tanto como sea posible los antecedentes de los en¬ 
trevistados y su organización. Con frecuencia este material se puede obtener del sitio Web 



Pasos que sieue el analista c¡e 
sistemas para la planeación 
de la entrevista. 


Pasos para la planeación de la entrevista 


1. Leer los : antecedentes: 

2. Establecer los objetivos de la entrevista. 

3. Decidir a quién entrevistar: 

4. :; Preparar al entrevistado..;:,-: 

5. Decidir el tipo de preguntas.y la 


estructura. 
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corporativo, de un informe anual actual, de un boletín corporativo o de cualquier publicación 
que explique el estado de la organización. Busque en Internet cualquier información corpo¬ 
rativa como la que se ofrece en Standard and Poor's. 

Conforme lea este material, ponga especial atención al lenguaje que utilicen los miem¬ 
bros de la organización para describirse a sí mismos y a su organización. El propósito es 
crear un vocabulario común que en un futuro le permita expresar preguntas de la entrevis¬ 
ta de una manera comprensible para su entrevistado. Otra ventaja de investigar su organiza¬ 
ción es maximizar el tiempo que invierta en las entrevistas; sin esta preparación podría per¬ 
der tiempo haciendo preguntas generales sobre los antecedentes. 

Establecer los objetivos de la entrevista Utilice los antecedentes que haya recopilado así 
como su propia experiencia para establecer los objetivos de la entrevista. Debe haber de 
cuatro a seis áreas clave referentes al procesamiento de la información y el comportamien¬ 
to relacionado con la toma de decisiones acerca de las cuales tendrá usted que hacer pre¬ 
guntas. Estas áreas incluyen fuentes de información, formatos de información, frecuencia de 
la toma de decisiones, cualidades de la información y estilo de la toma de decisiones. 

Decidir a quién entrevistar Cuando tenga que decidir a quién entrevistar, incluya a gente 
clave de todos los niveles que vayan a ser afectadas por el sistema de alguna manera. Es¬ 
fuércese por conseguir el equilibrio de tal manera que atienda las necesidades de tantos 
usuarios como sea posible. Su persona de contacto en la organización también tendrá algu¬ 
nas ideas sobre quién deba ser entrevistado. 

Preparar al entrevistado Prepare a la persona que va a ser entrevistada hablándole por 
anticipado o enviándole un mensaje de correo electrónico y dándole tiempo para pensar 
en la entrevista. Si va a realizar una entrevista a profundidad, puede enviar sus preguntas 
por correo electrónico con antelación para darle tiempo al entrevistado a que piense sus 
respuestas. Sin embargo, debido a que con la entrevista se pretende satisfacer muchos 
objetivos (incluyendo la creación de confianza y la observación del lugar de trabajo), 
normalmente ésta se debe realizar en persona y no por correo electrónico. Las entrevistas 
se deben llevar a cabo en 45 minutos o una hora a lo mucho. No importa cuánto parez¬ 
ca que sus entrevistados deseen ampliar la entrevista más allá de este límite, recuerde 
que cuando pasan tiempo con usted, no están haciendo su trabajo. Si las entrevistas duran 
más de una hora, es probable que los entrevistados se enfaden, aunque quizá oculten su 
disgusto. 

Decidir el tipo de preguntas y la estructura Escriba preguntas que abarquen las áreas clave 
de la toma de decisiones que haya descubierto al determinar los objetivos de la entrevista. 
Las técnicas apropiadas para preguntar son el corazón de la entrevista. Las preguntas tienen 
algunas formas básicas que usted debe conocer. Los dos tipos básicos de preguntas son las 
abiertas y las cerradas. Cada tipo de pregunta puede lograr resultados un poco diferentes a 
los de la otra, y cada una tiene ventajas y desventajas. Es necesario que usted piense en el 
efecto que tendrá cada tipo de pregunta. 

Es posible estructurar su entrevista de tres modos distintos: una estructura de pirámide, 
una estructura de embudo o una estructura de diamante. Cada uno es apropiado bajo condi¬ 
ciones distintas y tienen funciones diferentes, y se explicarán más adelante en este capítulo. 


TIPOS DE PREGUNTAS 


Preguntas abiertas Estas preguntas incluyen aquellas como "¿Qué piensa de poner a todos 
los gerentes en una intranet?" y "Explique por favor cómo toma una decisión de programa¬ 
ción de producción". Considere el término abiertas. En realidad, "abiertas" describe las opcio¬ 
nes del entrevistado para responder. Están abiertas. La respuesta puede ser de dos palabras 
o dos párrafos. En la figura 4.2 se muestran algunos ejemplos de preguntas abiertas. 
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Preguntas abiertas de una entrevista 



Las preguntas abiertas de 
una entrevista le conceden al 
entrevistado opciones abiertas 
para responder. Los ejemplos 
fueron seleccionados de diversas 
entrevistas y no se muestran en 
ningún orden especial. 


• ¿Cuál es su opinión del estado actual del comercio electrónico negocio 
a negocio en su empresa? 

• ¿Cuáles son los objetivos críticos de su departamento? 

• Una vez que los datos se envían a través del sitio Web, ¿cómo se procesan? 

• Describa el proceso de monitoreo que está disponible en línea. 

• ¿Cuáles son algunos de los errores comunes de captura de datos 

: que se cometen en este departamento? ' ■ 

• ¿Cuáles son las frustraciones más grandes que ha experimentado 
durante la transición al comercio electrónico? 


Las ventajas de utilizar las preguntas abiertas son muchas e incluyen las siguientes: 

1. Hacen que el entrevistado se sienta a gusto. 

2. Permiten al entrevistador entender el vocabulario del entrevistado, el cual refleja su 
educación, valores, actitudes y creencias. 

3. Proporcionan gran cantidad de detalles. 

4. Revelan nuevas líneas de preguntas que pudieron haber pasado desapercibidas. 

5. Hacen más interesante la entrevista para el entrevistado. 

6. Permiten más espontaneidad. 

7. Facilitan la forma de expresarse al entrevistador. 

8. Son un buen recurso si el entrevistador no está preparado para la entrevista. 

Como puede ver, las preguntas abiertas tienen varias ventajas. Sin embargo, también tienen 
muchas desventajas: 

1. Podrían dar como resultado muchos detalles irrelevantes. 

2. Posible pérdida del control de la entrevista. 

3. Permiten respuestas que podrían tomar más tiempo del debido para la cantidad útil de 
información obtenida. 

4. Dan la impresión de que el entrevistador es inexperto. 

5. Podrían dar la impresión de que el entrevistador "anda de pesca" sin un objetivo real en 
la entrevista. 

Debe considerar con cuidado las implicaciones de utilizar las preguntas abiertas para entre¬ 
vistar. 

Preguntas cerradas La alternativa a las preguntas abiertas se encuentra en el otro tipo de 
pregunta básica: las preguntas cerradas. Tales preguntas son de la forma básica: "¿Cuántos 
subordinados tiene?" Las respuestas posibles se cierran al entrevistado, debido a que sólo 
puede contestar con un número finito como "Ninguno", "Uno" o "Quince". En la figura 4.3 
se pueden encontrar algunos ejemplos de preguntas cerradas. 


iliilliiiiiiiiiiii! 

Las preguntas cerradas de una 
entrevista limitan las opciones de 
los encuestados. Los ejemplos 
se seleccionaron de entrevistas 
diferentes y no se muestran en 
ningún orden especial. 


Preguntas cerradas de una entrevista 

• ¿Cuántas veces por semana se actuáliza'el almacén del; proyecto? 

• En promedio, ¿cuántas llamadas recibe mensualmeñteei centro 

d e atención’ a i 1 1 ifilI s s !■■ /•: ■ ,<»>■' : 

• ¿Cuál de las siguientes fuentes de información es más valiosa para 

•usted?:’; ’ : : }"•: I *’ • .. v ;1 ' : \' 

0 Formularios de quejaílenados por el : cliente;-: {*¡ :u,.\; ,;*\ 

0 Quejas recibídaspor correo de los clientes que 'visitan el sitio Web. 
•*. 0 Interacción frentea frente c o n los ol¡ éntesvri : ; : : y :; : .; v : 

. ' • • II e r c a 1 s ¡a devuelta., '.-C ’ :; ll '-i" -V.;’ 

• Mencione sus dosprioridades príncipales"par.a mejorar; 

la infraestructura de tecnología. ■**;* , ; 

• ¿Quién recibe esta Información? • r : •;= ; ■: 
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Preguntas bipolares de una entrevista 

• ¿Utiliza la Web para proporcionar información a los distribuidores? 

• ¿Está de acuerdo o en desacuerdo con que el comercio electrónico . 

■ en la Web carece de seguridad? . 

• ¿Desea recibir una impresión de su estado de cuenta cada mes? 

• ¿Su sitio Web mantiene una pagina de preguntas frecuentes (FAQ) 
para los empleados con dudas respecto aj proceso de la nómina?; 

• ¿Este:formulario está completo? .pi-AS::ifiií&üPrF; 



•: as i-érla/es di-dra 
entrevista son: un tipo-especial 
de pregunta cerrada. Los 
ejemplos se seleccionaron de 
las diferentes entrevistas y no: 
se muestran en ningún orden 
: especiad L 


Una pregunta cerrada limita la respuesta disponible para el entrevistado. Tal vez usted 
se haya familiarizado con las preguntas cerradas a través de los exámenes de opción múlti¬ 
ple de la universidad. Le dan una pregunta y cinco respuestas, pero no le permiten anotar su 
propia respuesta y aún así se espera que conteste la pregunta correctamente. 

Un tipo especial de pregunta cerrada es la pregunta bipolar. Este tipo de pregunta limi¬ 
ta aún más las opciones del entrevistado pues sólo le permite una opción en cada polo, co¬ 
mo sí o no, verdadero o falso, de acuerdo o desacuerdo. En la figura 4.4 se pueden encontrar 
ejemplos de preguntas bipolares. 

Las ventajas de utilizar preguntas cerradas de cualquiera de los dos tipos incluyen lo si¬ 
guiente: 

1. Ahorrar tiempo. 

2. Comparar las entrevistas fácilmente. 

3. Ir al grano. 

4. Mantener el control durante la entrevista. 

5. Cubrir terreno rápidamente. 

6. Conseguir datos relevantes. 

Sin embargo, las desventajas de utilizar preguntas cerradas son considerables. Dichas des¬ 
ventajas incluyen lo siguiente: 

1. Aburren al entrevistado. 

2. No permiten obtener gran cantidad de detalles [debido a que el entrevistador propor¬ 
ciona el marco de referencia para el entrevistado]. 

3. Olvidar las ideas principales por la razón anterior. 

4. No ayudan a forjar una relación cercana entre el entrevistador y el entrevistado. 


Así, en su calidad de entrevistador, usted debe pensar cuidadosamente los tipos de pregun¬ 
ta que utilizará. 

Las preguntas abiertas y cerradas tienen ventajas y desventajas, como se muestra en la 
figura 4.5. Observe que al elegir un tipo de pregunta sobre el otro realmente involucra un 
intercambio; aunque una pregunta abierta ofrece amplitud y profundidad para la contesta¬ 
ción, las respuestas a las preguntas abiertas son difíciles de analizar. 


Abierta 

Baja 

Cor aci cae de los datos 4 i , 

Cerrada 

Alta 

Baja 

Uso eficiente del tiempo- ¡jíj A- : ' 

Alta 

Baja 

Precisión de tos.datos 

Alta 

Mucha 

Amplitud y profundidad 

Poca 

Mucha 

Habilidad requerida del entrevistador 

Poca 

Difícil 

Facilidad de análisis 

Fácil 



Atributos de las preguntas 
abierta y cerrada. 
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Sondeos 
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Los sondeos permiten al analista 
de sistemas ahondar en las 
preguntas para conseguir 
respuestas más detalladas. Los 
ejemplos se seleccionaron de las 
diferentes entrevistas y no se 
muestran en ningún orden 
especial. 


• ¿Porqué? 

• Dé un ejemplo de la manera en que se ha integrado el comercio 
electrónico en sus procesos de negocios. 

• Por favor proporcione un ejemplo de los problemas de seguridad 

que está experimentando con su sistema de pago de facturas en línea. 

• Usted mencionó ambas soluciones, una intranet y una extranet. Por 
favor dé; un ejemplo de la forma en que considera que se diferencian. 

• ¿Qué lo hace sentirse de esa manera? 

• Dígame, paso a paso, lo que sucede después de que un cliente 
hace clic en el botón "Enviar" del formulario de registro en la Web. 


Sondeos Un tercer tipo de pregunta es el sondeo o seguimiento. El sondeo más profundo 
es el más simple: la pregunta "¿Por qué?" Otros sondeos son "¿Me puede dar un ejemplo?" y 
"¿Me lo puede explicar con más detalle?" En la figura 4.6 se pueden encontrar algunos 
ejemplos de preguntas de sondeo. El propósito del sondeo es ir más allá de la respuesta ini¬ 
cial para conseguir mayor significado, clarificar, obtener y ampliar la opinión del entrevista¬ 
do. Los sondeos pueden constar de preguntas abiertas o cerradas. 

El sondeo es fundamental. La mayoría de los entrevistadores principiantes muestran re¬ 
ticencia al uso de los sondeos y, por consiguiente, aceptan respuestas superficiales. Por lo 
regular agradecen que los empleados les concedan entrevistas y se sienten obligados hasta 
cierto punto a aceptar cortésmente las respuestas tajantes. 


CÓMO COLOCAR LAS PREGUNTAS EN UNA SECUENCIA LÓGICA 

Así como hay dos formas generalmente reconocidas de razonamiento —inductivo y deduc¬ 
tivo—, también hay dos formas similares de organizar sus entrevistas. Una tercera combina 
los métodos inductivo y deductivo. 



La estructura de pirámide para 
entrevistar va de las preguntas 
específicas a las generales. 



¿Ha considerado otros métodos 
para mejorar la seguridad 
de los datos corporativos? 


En general, ¿qué opina de la seguridad dé los 
versus la importancia del acceso a Internet? 


„. y terminan 
con.una 
pregunta 


genei 1 


¡ral. 


I Las estructuras 
d 6 pirámide inician 
í con una pregunta 
j ¡ : \ . específica." 
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OPORTUNIDAD 


CONSULTORIA 


FORTALEZCA SUS TIPOS DE PREGUNTA 


Strongbodies, una importante cadena loca! de clubes deportivos, ha 
experimentado un crecimiento espectacular en los últimos cinco años. 
Los directivos quieren depurar su proceso de toma de decisiones para la 
compra de nuevo equipo de fisicocultuñsmo. Actualmente, los gerentes 
escuchan a los clientes, asisten a las exposiciones profesionales, exami¬ 
nan la publicidad y solicitan nuevas compras de equipo con base en sus; 
percepciones subjetivas. Posteriormente, estas compras son aprobadas 
o rechazadas por Harry Mussels. . v. . 

Harry es la primera persona que usted entrevistará. Es un gerente de 
división, de 37 años, que dirige cinco clubes del área. Viaja por toda la 
ciudad para llegar a las dispersas instalaciones délos clubes. Harry 
cuenta con una oficina en las instalaciones del Este, aunque está allí 
menos de una cuarta parte de su tiempo. • 

Además, cuando Harry está en un club, está ocupado contestando 
llamadas telefónicas relacionadas con los negocios, resolviendo al ins-; 


tante problemas que le presentan los gerentes e ¡nteractuando con los 
miembros del club. Su tiempo es breve y, para compensarlo, se ha vuelto 
un gerente de división eficiente y extremadamente bien organizado. Él no 
juede concederle mucho tiempo para la entrevista. Sin embargo, la 
aportación que puede hacer es importante y siente que él sería el princi¬ 
pal beneficiado con el sistema propuesto. 

¿Qué tipo de pregunta podría ser el más adecuado para su entrevis¬ 
ta con Harry? ¿Por qué éste tipo es el más apropiado? ¿Cómo afectará su 
elección del tipo de pregunta la cantidad de tiempo que empleará en 
prepararse para entrevistar a Harry? Escriba de cinco a 10 preguntas de 
este tipo. ¿Qué otras técnicas podría utilizar para complementar la infor¬ 
mación que no obtenga a través de ese tipo de pregunta? Explique en un 
párrafo su respuesta. 


Uso de una estructura de pirámide La organización inductiva de preguntas de la entrevis¬ 
ta se puede visualizar como si se tuviera una forma de pirámide. Con base en esta forma, el 
entrevistador empieza con preguntas, a menudo cerradas, muy detalladas. Posteriormente, 
el entrevistador extiende los temas permitiendo preguntas abiertas y respuestas más gene¬ 
ralizadas, como se muestra en la figura 4.7. 

Debe utilizar una estructura de pirámide si cree que su entrevistado necesita motiva¬ 
ción para profundizar en el tema. También es conveniente utilizar una estructura de pirámi¬ 
de para la secuencia de las preguntas cuando desea una opinión concluyente del tema. Tal 
es el caso de la pregunta final; "En general, ¿qué opina de la seguridad de los datos versus la 
importancia del acceso a Internet?" 

Uso de una estructura de embudo En el segundo tipo de estructura, el entrevistador adop¬ 
ta un método deductivo al iniciar con preguntas generales y abiertas, y luego limitar las po¬ 
sibles respuestas utilizando preguntas cerradas. Esta estructura de entrevista se puede visua¬ 
lizar como una forma de embudo, como se representa en la figura 4.8. El uso del método de 
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La estructura de diamante 


para entrevistar combina las 
estructuras de pirámide y 
de embudo. 



estructura de embudo proporciona una forma cómoda y sencilla de empezar una entrevis¬ 
ta. La secuencia de preguntas en forma de embudo también es útil cuando el entrevistado 
tiene opiniones fuertes acerca del tema y necesita libertad para expresar sus emociones. 


Uso de una estructura de diamante Con frecuencia es mejor una combinación de las dos 
estructuras anteriores, lo cual da como resultado una estructura de diamante. Esta estruc¬ 
tura implica empezar de una manera muy específica, después se examinan los aspectos ge¬ 
nerales y finalmente se termina con una conclusión muy específica, como se muestra en la 
figura 4.9. 

El entrevistador empieza con preguntas cerradas sencillas que permiten calentar el pro¬ 
ceso de la entrevista. A la mitad de la entrevista, se le pide al entrevistado que dé su opinión 
sobre temas amplios que obviamente no tienen una respuesta "correcta". Posteriormente, el 
entrevistador limita de nuevo las preguntas para obtener respuestas específicas, con lo cual 
propicia, tanto para él como para el entrevistado, una forma de cerrar la entrevista. La es¬ 
tructura de diamante combina las fortalezas de los otros dos métodos, pero tiene la desven¬ 
taja de tomar mucho más tiempo que cualquiera de las otras estructuras. 

El final de la entrevista es un punto apropiado para hacer una pregunta importante: 
"¿Hay algo que no hayamos tratado y que usted sienta que es importante que yo sepa?" 
Considerada por lo general como una pregunta sistemática por el entrevistado, con frecuen¬ 
cia la respuesta será "No". Sin embargo, a usted le interesan los casos en que esta pregunta 
supera las trabas y da paso al flujo de muchos datos nuevos. 

Al terminar la entrevista, haga un resumen y de retroalimentación sobre sus impresio¬ 
nes generales. Informe al entrevistado qué procede y lo que usted y otros miembros del 
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"Bien, le advertí que las cosas aquí en MRE no siempre eran sencillas. Para este momento ya 
conoce a muchos de nuestros empleados importantes y está empezando a enterarse de có¬ 
mo están las cosas. ¿Quién habría pensado que algunas decisiones inocentes sobre el hard¬ 
ware, como la de comprar un COMTEX o un Shiroma, desatarían tal hostilidad? Bien, 
siempre sostengo que se vive y se aprende. [Por lo menos ahora sabrá lo que no le conviene 
cuando tenga que empezar a recomendar el hardware!" 

"Es curioso que no todas las preguntas sean iguales. Yo mismo prefiero las preguntas 
abiertas, pero cuando tengo que contestarlas, no siempre es fácil. ¿Ha aprovechado la opor¬ 
tunidad de ver las oficinas de los entrevistados cuando ha estado allí para hacer sus entrevis¬ 
tas? Puede aprender mucho sobre este asunto utilizando un método de observación estruc¬ 
turado como STROBE". 


PREGUNTAS DE HYPERCASE 

1. Utilizando las preguntas de la entrevista planteadas en el HyperCase, proporcione cin¬ 
co ejemplos de preguntas abiertas y cinco de preguntas cerradas. Explique por qué sus 
ejemplos están correctamente clasificados como preguntas abiertas o cerradas. 

2. Mencione tres preguntas de sondeo que formen parte de las entrevistas del HyperCase. 
En particular, ¿qué aprendió al ahondar en las preguntas que le hizo a Snowden Evans? 



Questions 

¿ ** Good tnoming, Mr. Hill. I'm from the Management Information Systems department working on the Global 
i** EngineeringManagementSystemproject.I wouldliketo askyousome questions thatwillhelpto getan 
overview ofthe project. 

'Sva What are your divisioris goals? 

Could you tell me about the merger ofTraining and Management Systems: how did it come about» and 
é" why? 


fjFJ6UR£4.HClliÉl 


■r,.:.14 a-iCÍ-JÍ ¿S L’i ¿i liU&l 

Al colocar el puntero del ratón en una pregunta de HyperCase se mostrará una respuesta 
(el sitio se encuentra en inglés). 
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sobre JAD para que se entere de algunas de sus ventajas y desventajas en comparación con 
las entrevistas uno a uno. 


CONDICIONES QUE APOYAN EL USO DE JAD 

La siguiente lista de condiciones le ayudará a decidir cuándo puede ser provechoso el uso 
de JAD. Considere el uso del diseño conjunto de aplicaciones cuando: 

1. Los grupos de usuarios están intranquilos y quieren algo nuevo, no una solución común 
a un problema típico. 

2. La cultura organizacional apoya los métodos conjuntos de resolución de problemas en¬ 
tre diversos niveles de empleados. 

3. Los analistas prevén que la cantidad de ideas generadas por medio de las entrevistas 
uno a uno no será tan abundante como la cantidad de ideas que se podrían obtener de 
un ejercicio en grupo. 

4. El flujo de trabajo de la organización permite la ausencia de personal importante du¬ 
rante un periodo de dos a cuatro días. 

QUIÉN ESTÁ INVOLUCRADO 

Las sesiones de diseño conjunto de aplicaciones incluyen una variedad de participantes —ana¬ 
listas, usuarios, ejecutivos, etc.—, que aportarán su experiencia y habilidades, en diferen¬ 
te medida, a las sesiones. Aquí su principal interés es que todos los miembros del equipo 
que participarán en el proyecto se comprometan e involucren con el enfoque JAD. Escoja 
un patrocinador ejecutivo, una persona de experiencia que presentará y concluirá la sesión 
de JAD. De preferencia, seleccione a un ejecutivo del grupo de usuarios que tenga algún ti¬ 
po de autoridad sobre las personas del área de sistemas de información que trabajen en el 
proyecto. Esta persona será un símbolo visible e importante del compromiso de la organiza¬ 
ción con el proyecto de sistemas. 

Por lo menos un analista del área de sistemas de información debe estar presente, pero 
a menudo el analista toma un rol pasivo, a diferencia de lo que ocurre en la entrevista tradi¬ 
cional en la cual el analista controla la interacción. Como analista del proyecto, usted debe 
estar presente en la sesión de JAD para escuchar lo que dicen los usuarios y lo que necesi¬ 
tan. Además, usted tendrá que dar una opinión especializada en caso que en la sesión de 
JAD se proponga alguna solución de un costo desproporcionado. Sin este tipo de retroali- 
mentación inmediata, las soluciones poco realistas con costos excesivos podrían colarse en 
la propuesta y ser difíciles de eliminar más tarde. 

Es conveniente seleccionar de ocho a 12 usuarios de cualquier nivel para participar, en 
las sesiones de JAD. Procure seleccionar a usuarios por encima del nivel operativo, que ten¬ 
gan capacidad para explicar qué información requieren para realizar sus trabajos, así como 
las características que les agradarían en un sistema de cómputo nuevo o mejorado. 

El líder de la sesión no debe ser un experto en el análisis y diseño de sistemas sino al¬ 
guien que cuente con habilidades de comunicación excelentes para facilitar las interacciones 
apropiadas. Tome nota que no es conveniente designar a un líder de sesión que le reporte a 
una persona del grupo. Para evitar esta posibilidad, una organización podría contratar a un 
consultor externo que funja como líder de sesión. El punto es contar con una persona que 
atraiga la atención del grupo para tratar las cuestiones importantes de los sistemas, negociar 
satisfactoriamente y resolver los conflictos, y ayudar a los miembros del grupo a alcanzar un 
acuerdo general. 

Su sesión de JAD también debe incluir a uno o dos observadores que sean analistas o 
expertos técnicos de otras áreas funcionales para ofrecer explicaciones y consejos técnicos al 
grupo durante las sesiones. Además, un miembro del departamento de sistemas de informa¬ 
ción debe asistir a las sesiones de JAD para redactar formalmente todo lo que se haga. 


DÓNDE CELEBRAR LAS REUNIONES DE JAD 

De ser posible, recomendamos que las sesiones de dos a cuatro días se realicen fuera de las 
oficinas de la organización, en ambientes cómodos. Algunos grupos usan los centros ejecu- 
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.¿U.N...ANALISTAJDE. SISTEMAS, SUPONGO? 


"¿Sabe lo qué opino del trabajo que realizó el último equipo de ana¬ 
listas de sistemas? Generaron una selva de documentos impresos. Para 
averiguar cuánto nos cuesta la materia prima, tengo que abrirme paso 
éntrela maleza de datos con una pluma.Tengo quetachartodo lo que es 
irrelevante. A veces arranco físicamente el exceso de vegetación hasta 
que alcanzo los números que necesito", dice Henry Stanley, supervisor de 
contabilidad de la compañía Zenith Glass. Mientras usted lo entrevista, 
él señala tristemente hacia una pila desordenada de documentos muti¬ 
lados que crece junto a su escritorio. 


Identifique la metáfora de que se vale Henry para describir la canti¬ 
dad de documentos que está recibiendo y la accesibilidad a la informa¬ 
ción que contienen. En un párrafo, explique la manera en que este paso 
le ayuda a entender la actitud de Henry hacia cualquiertrabajo propuesto 
por su equipo de análisis de sistemas. En un párrafo, adopte la metáfo¬ 
ra de Henry y amplíela en un sentido más positivo durante su entrevista 
con él. 


tivos o incluso las instalaciones de apoyo a la toma de decisiones en grupo que están disponi¬ 
bles en las principales universidades. La idea es minimizar las distracciones y responsabilida¬ 
des cotidianas inherentes al trabajo regular de los participantes. La propia sala debe albergar 
cómodamente a la cantidad de personas invitadas. El equipo de apoyo a presentaciones, co¬ 
mo mínimo incluye dos proyectores de transparencias, un pizarrón, un rotafolio y acceso a 
una copiadora. Las salas destinadas al apoyo a la toma de decisiones en grupo también pro¬ 
porcionan PCs conectadas a una red, un sistema de proyección y software escrito para faci¬ 
litar la interacción de grupos y minimizar el comportamiento improductivo de los mismos. 

Programe su sesión de JAD cuando todos los participantes puedan comprometerse a 
asistir. No realice las sesiones a menos que todos aquellos que haya invitado realmente asistan. 
Esta regla es importante para el éxito de las sesiones. Asegúrese de que todos los participantes 
reciban una agenda antes de la reunión, y considere la idea de realizar una reunión informa¬ 
tiva, de alrededor de medio día de duración, una semana más o menos antes del taller para 
que los involucrados sepan lo que se espera de ellos. Una reunión previa de este tipo le per¬ 
mite moverse rápidamente y desenvolverse con confianza una vez que se haya iniciado la 
reunión definitiva. 

REALIZACIÓN DE UN ANÁLISIS ESTRUCTURADO DE LAS ACTIVIDADES DEL PROYECTO 

IBM recomienda que las sesiones de JAD examinen los siguientes puntos en el proyecto de 
sistemas propuesto: planeación, recepción, procesamiento/seguimiento de recibos, supervi¬ 
sión y asignación, procesamiento, registro, envío y evaluación. Se deben plantear y responder 
en cada tema las preguntas quién, qué, cómo, dónde y por qué. Es evidente que los sistemas 
interactivos ad hoc como los sistemas de apoyo a la toma de decisiones y otros tipos de sis¬ 
temas que dependen del estilo del encargado de tomar las decisiones (incluso los sistemas 
de prototipos) no se analizan con tanta facilidad como con el enfoque estructurado de JAD. 

En su calidad de analista en las sesiones de JAD, usted debe recibir las notas del redac¬ 
tor y debe preparar un documento de especificaciones técnicas con base en lo que haya 
ocurrido en la reunión. Presente sistemáticamente los objetivos de los directivos así como el 
alcance y los límites del proyecto. También debe incluir las partes específicas del sistema, 
como detalles sobre los diseños de pantallas e informes. 

BENEFICIOS POTENCIALES DEL USO DE JAD EN LUGAR DE LAS ENTREVISTAS TRADICIONALES 

Hay cuatro beneficios potenciales que usted, los usuarios y su equipo de análisis de sistemas 
deben considerar cuando evalúen la posibilidad de usar el diseño conjunto de aplicaciones. 
El primer beneficio potencial es el ahorro de tiempo sobre las entrevistas tradicionales uno 
a uno. Algunas organizaciones han estimado que las sesiones de JAD ocupan 15 por ciento 
menos tiempo que el enfoque tradicional. 

A la par con el ahorro de tiempo está la posibilidad de un desarrollo rápido a través de 
JAD. Dado que las entrevistas de usuarios no se realizan consecutivamente durante un pe¬ 
riodo de semanas o meses, el desarrollo puede proceder con mayor rapidez. 
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Un tercer beneficio es la posibilidad de mejorar el concepto de propiedad del sistema 
de información. Como analistas, siempre nos esforzamos por involucrar a los usuarios en 
formas significativas y los animamos a que sientan como suyos los sistemas que estemos di¬ 
señando. Debido a su naturaleza interactiva y a su alta visibilidad, JAD ayuda a los usuarios 
a involucrarse en las etapas tempranas de los proyectos de sistemas y le da seriedad a la re- 
troalimentación que proporcionan. El trabajo continuo en una sesión de JAD ayuda a refle¬ 
jar las ideas del usuario en el diseño final 

Un beneficio final de participar en las sesiones de JAD es el desarrollo de diseños crea¬ 
tivos. El carácter interactivo de JAD tiene mucho en común con las técnicas de la lluvia de 
ideas que generan nuevas ideas y nuevas combinaciones de ideas gracias a un entorno diná¬ 
mico y estimulante. Los diseños pueden evolucionar a través de interacciones simplificadas, 
en lugar de en un aislamiento relativo. 

POTENCÍALES DESVENTAJAS DEL USO DEJAD 

Hay tres desventajas o peligros que usted también debe tomar en cuenta cuando tenga que 
elegir entre entrevistas tradicionales uno a uno o el uso del diseño conjunto de aplicaciones. 
La primera desventaja es que JAD requiere que todos los participantes dediquen una gran 
cantidad de tiempo. Dado que JAD requiere un compromiso de dos a cuatro días, no es po¬ 
sible hacer cualquier otra actividad al mismo tiempo o cambiar el horario de las actividades, 
como se hace típicamente en las entrevistas uno a uno. 

El segundo peligro se manifiesta si la preparación para las sesiones de JAD es inadecuada 
en cualquier aspecto o si el informe de seguimiento y la documentación de especificaciones 
están incompletos. En estos casos los diseños resultantes podrían ser poco satisfactorios. Es 
necesario que muchas variables se conjuguen correctamente para que JAD tenga éxito. En 
caso contrario, muchas cosas pueden salir mal. El éxito derivado de las sesiones de JAD es 
menos predecible que aquel que se consigue a través de las entrevistas tradicionales. 

Por último, quizá las habilidades y cultura que requiere la organización no se hayan de¬ 
sarrollado lo suficiente para permitir el esfuerzo concertado indispensable para ser produc¬ 
tivo en un escenario JAD. A la postre usted tendrá que determinar si la organización se 
compromete de verdad con, y está preparada para, este enfoque. 


USO DE CUESTIONARIOS 

El uso de cuestionarios es una técnica de recopilación de información que permite a los 
analistas de sistemas estudiar las actitudes, creencias, comportamiento y características de 
muchas personas importantes en la organización que podrían resultar afectadas por los sis¬ 
temas actuales y los propuestos. Las actitudes consisten en lo que las personas de la organi¬ 
zación dicen que quieren (en un nuevo sistema, por ejemplo); las creencias son lo que las 
personas realmente piensan que es verdad; el comportamiento es lo que los miembros de la 
organización hacen, y las características son propiedades de las personas o cosas. 

Es posible cuantificar las respuestas conseguidas a través de cuestionarios (también co¬ 
nocidos como encuestas) que usan preguntas cerradas. Si usted encuesta personas a través 
de correo electrónico o la Web, puede utilizar software para convertir las respuestas electró¬ 
nicas directamente a tablas de datos para análisis mediante una aplicación de hoja de cálcu¬ 
lo o paquetes de software estadísticos. Las respuestas a cuestionarios que utilizan preguntas 
abiertas se analizan e interpretan de otras maneras. La redacción que utilice el analista de 
sistemas influye en las respuestas a preguntas sobre actitudes y creencias. 

Al usar cuestionarios, el analista podría estar buscando cuantificar lo que se haya descu¬ 
bierto en las entrevistas. Además, éstos podrían usarse para determinar qué tan extendido o 
limitado es en realidad un sentimiento expresado en una entrevista. Por otra parte, los cues¬ 
tionarios se pueden usar para encuestar a una muestra considerable de usuarios de sistemas 
con el fin de detectar problemas o poner de manifiesto cuestiones importantes antes de que 
se realicen las entrevistas. 

A lo largo de este capítulo comparamos y contrastamos los cuestionarios con las entre¬ 
vistas. Hay muchas similitudes entre ambas técnicas, y quizá lo ideal sería usarlas en conjun- 
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to, ya sea dando seguimiento en una entrevista a las respuestas confusas del cuestionario o 
diseñando los cuestionarios con base en lo que se descubra en las entrevistas. Sin embargo, 
cada técnica tiene sus propias funciones específicas, y no siempre es necesario o convenien¬ 
te utilizarlas en combinación. 


PLANEAOSÓN DEL USO DE CUESTIONARIOS 

A primera vista los cuestionarios podrían parecer una manera rápida de recopilar grandes 
cantidades de datos sobre la opinión que los usuarios tienen del sistema actual, sobre los 
problemas que experimentan con su trabajo y sobre lo que la gente espera de un sistema 
nuevo o uno modificado. Aunque es cierto que usted puede recopilar mucha información a 
través de los cuestionarios sin invertir tiempo en las entrevistas cara a cara, el desarrollo de 
un cuestionario útil implica una considerable cantidad de tiempo de planeación. Cuando 
usted decide encuestar a los usuarios por medio del correo electrónico o la Web, enfrenta 
aspectos de planeación adicionales acerca de la confidencialidad, la autenticación de identi¬ 
dad y problemas de múltiples respuestas. 

Lo primero que debe usted decidir es qué fines persigue al utilizar una encuesta. Por 
ejemplo, si desea saber qué porcentaje de usuarios prefiere una página de preguntas fre¬ 
cuentes (FAQ) como un medio de aprender aspectos sobre nuevos paquetes de software, 
un cuestionario podría ser la técnica correcta. En cambio, si lo que desea es un análisis 
profundo del proceso de toma de decisiones de un gerente, una entrevista es una mejor 
opción. 

A continuación mencionamos algunas directrices que le pueden servir para decidir si es 
apropiado el uso de cuestionarios. Considere el uso de cuestionarios si: 

1. Las personas que necesita encuestar se encuentran en ubicaciones dispersas (diferentes 
instalaciones de la misma corporación). 

2. Una gran cantidad de personas está involucrada en el proyecto de sistemas, y es impor¬ 
tante saber qué proporción de un grupo dado (por ejemplo, los directivos) aprueba o 
desaprueba una característica específica del sistema propuesto. 

3. Está haciendo un estudio preliminar y desea medir la opinión general antes de que se 
determine el rumbo que tomará el proyecto de sistemas. 

4. Desea tener la certeza de que en las entrevistas de seguimiento se identificará y aborda¬ 
rá cualquier problema relacionado con el sistema actual. 

Una vez que haya determinado que tiene buenos motivos para usar un cuestionario y 
que haya precisado los objetivos que se cumplirán por medio de éste, puede proceder a ela¬ 
borar las preguntas. 


REDACCIÓN DE PREGUNTAS 

La diferencia más importante entre las preguntas que se utilizan para la mayoría de las en¬ 
trevistas y aquellas usadas en los cuestionarios es que las entrevistas permiten la interacción 
entre las preguntas y sus significados. En una entrevista el analista tiene la oportunidad de 
refinar una pregunta, definir un término confuso, cambiar el curso de las preguntas, respon¬ 
der a una mirada desconcertada y controlar generalmente el contexto. 

En un cuestionario sólo se pueden aprovechar algunas de estas oportunidades. Por lo 
tanto, para el analista, las preguntas deben tener suficiente claridad, el flujo del cuestionario 
debe ser convincente, las preguntas de los encuestados deben anticiparse y la aplicación del 
cuestionario debe planearse en detalle. 

Los tipos básicos de preguntas que se utilizan en los cuestionarios son las abiertas y las 
cerradas, al igual que en las entrevistas. Debido a las limitaciones propias de los cuestiona¬ 
rios, se justifica una explicación adicional de los tipos de preguntas de éstos. 


Preguntas abiertas Recuerde que las preguntas abiertas (o enunciados) son aquellas que 
dejan abiertas al encuestado todas las posibles opciones de respuesta. Por ejemplo, las pre- 
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guntas abiertas en un cuestionario podrían ser: "Describa los problemas que esté experi¬ 
mentando actualmente con la impresión de informes" o "En su opinión, ¿qué tan útiles son 
los manuales de usuario para el paquete de contabilidad del sistema actual?" 

Cuando redacte preguntas abiertas para un cuestionario, anticipe qué tipo de respuesta 
obtendrá. Por ejemplo, si hace la pregunta "¿Qué piensa del sistema?", las respuestas po¬ 
drían ser demasiado amplias para interpretarlas o compararlas con precisión. En conse¬ 
cuencia, aun cuando redacte una pregunta abierta, debe ser suficientemente específica para 
guiar al encuestado a responder de una manera particular. (En la figura 4.10 se pueden en¬ 
contrar ejemplos de preguntas abiertas.} 

Las preguntas abiertas son particularmente adecuadas para situaciones en que usted 
desea descubrir las opiniones de miembros de la organización sobre algún aspecto del siste- 
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ma, ya sea un producto o un proceso. En estos casos, en los que es imposible listar eficaz¬ 
mente todas las posibles respuestas a una pregunta, usted podría recurrir a las preguntas 
abiertas. 

Preguntas cerradas Recuerde que las preguntas cerradas (o enunciados) son aquellas que 
limitan o cierran las opciones de respuesta disponibles para el encuestado. Por ejemplo, en 
la figura 4.11, el enunciado de la pregunta 23 ("Abajo se muestran los seis paquetes de soft¬ 
ware disponibles actualmente en el Centro de Información. Por favor marque el paquete 
que use con más frecuencia") es cerrado. Observe que no se pregunta a los encuestados 
por qué prefieren el paquete, ni se les pide que seleccionen más de uno, aun cuando ésta sea 
una respuesta más representativa. 
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Las preguntas cerradas deben usarse cuando el analista de sistemas puede listar eficaz¬ 
mente todas las posibles respuestas a la pregunta y cuando todas las respuestas listadas son 
mutuamente excluyentes, es decir, que al elegir una se impida la elección de cualquiera de 
las demás. 

Use preguntas cerradas cuando desee encuestar a una muestra considerable de perso¬ 
nas. La razón es obvia cuando usted empieza a imaginar la apariencia que tendrán los datos 
que recopilará. Si utiliza sólo preguntas abiertas para centenares de personas, el análisis y la 
interpretación correctos de sus respuestas se vuelve imposible sin la ayuda de un programa 
computarizado de análisis de contenido. 

Hay ventajas y desventajas involucradas en la elección de las preguntas abiertas o cerra¬ 
das que se usan en los cuestionarios. La figura 4.12 resume estos compromisos. Observe que 
las respuestas a las preguntas abiertas pueden ayudar a los analistas a obtener una alta com¬ 
prensión preliminar, así como una alta amplitud y profundidad, sobre un tema. Aunque la 
redacción de las preguntas abiertas es sencilla, sus respuestas son difíciles y su análisis toma 
mucho tiempo. 

Cuando nos referimos a la redacción de preguntas cerradas con preguntas en orden o en 
desorden, a menudo nos referimos al proceso como escalamiento. El uso de escalas en las 
encuestas se explica con detalle en una sección posterior. 

La elección del vocabulario Al igual que ocurre en las entrevistas, el lenguaje de los cues¬ 
tionarios es un aspecto muy importante para su eficacia. Aun cuando el analista de sistemas 
tenga un conjunto establecido de preguntas acerca del desarrollo de sistemas, es convenien¬ 
te que las redacte en tal forma que reflejen la propia terminología del negocio. 

Los encuestados aprecian el esfuerzo de alguien que se toma el tiempo para redactar un 
cuestionario que refleje la manera en que ellos usan el lenguaje. Por ejemplo, si en el nego¬ 
cio se emplea el término supervisores en lugar de gerentes, o unidades en vez de departamen¬ 
tos, al incorporar estos términos en el cuestionario facilita a los encuestados que los asocien 
con el significado de las preguntas. De esta manera, la interpretación precisa de las respues¬ 
tas será más sencilla y los encuestados se mostrarán, en general, más entusiasmados. 

Para verificar si el lenguaje usado en el cuestionario es similar al de los encuestados, 
pruebe algunas preguntas de ejemplo en un grupo piloto [grupo de prueba}. Pídales que 
pongan especial atención en el buen uso de la redacción y que cambien cualquier palabra 
que consideren inapropiada. 

A continuación mencionamos algunos lincamientos útiles para la elección del lenguaje 
del cuestionario: 

1. Use el lenguaje de los encuestados siempre que sea posible. Utilice una redacción 
sencilla. 

2. Esfuércese por ser específico en lugar de divagar en la redacción. También evite las pre¬ 
guntas demasiado específicas. 

3. Haga preguntas breves. 

4. No sea condescendiente con los encuestados ni los subestime con opciones de lenguaje 
de bajo nivel. 
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5. Evite la parcialidad en la redacción. Evitar la parcialidad implica también evitar pre¬ 
guntas ofensivas. 

6. Dirija las preguntas a los encuestados adecuados (es decir, aquellos que las puedan res¬ 
ponder]. No dé por sentado que éstos tendrán demasiado conocimiento. 

7. Asegúrese de que el aspecto técnico de las preguntas es preciso antes de incluirlas. 

8. Use software para verificar que el nivel de redacción de las preguntas sea apropiado pa¬ 
ra los encuestados. 


USO DE ESCALAS EN LOS CUESTIONARIOS 

El escalamiento es el proceso consistente en asignar números u otros símbolos a un atribu¬ 
to o característica con propósitos de medición. Las escalas son a menudo arbitrarias y en al¬ 
gunos casos no son únicas. Por ejemplo, la temperatura se mide de varias maneras; los dos 
más comunes son la escala Fahrenheit (donde el punto de congelamiento del agua ocurre a 
32 grados y el de ebullición a 212 grados] y la escala Celsius (donde el punto de congela¬ 
miento ocurre a 0 grados y el de ebullición a 100 grados]. 

Medición Por lo general, los analistas de sistemas utilizan dos diferentes formas de escalas 
de medición: 

1. las escalas nominales y 

2. las escalas de intervalos. 

Las escalas nominales se utilizan para clasificar cosas. Una pregunta como: 

¿Qué tipo de software usa más? 

1 = Un procesador de texto 

2 = Una hoja de cálculo 

3 = Una base de datos 

4 = Un programa de correo electrónico 

se vale de una escala nominal. Obviamente, las escalas nominales son las formas de medi¬ 
ción más débiles. Por lo general, todo lo que el analista puede hacer con ellas es obtener los 
totales para cada clasificación. 

Las escalas de intervalos poseen la característica de que los intervalos entre cada uno 
de los números son iguales. Debido a esta característica pueden realizarse operaciones 
matemáticas en los datos del cuestionario, lo cual da lugar a un análisis más completo. Las 
escalas Fahrenheit y Celsius, que miden la temperatura, son ejemplos de escalas de inter¬ 
valos. 

Definitivamente, el ejemplo anterior del Centro de Información no se puede conside¬ 
rar como ejemplo de escala de intervalos, pero al fijar la escala en ambos extremos, el ana¬ 
lista podría dar por sentado que el encuestado percibirá que los intervalos son iguales: 

¿Qué tan útil es el apoyo que ofrece el Grupo de Soporte Técnico? 

No tiene utilidad Es sumamente 

alguna útil 

1 2 3 4 5 

Si el analista de sistemas hace esta suposición, puede realizar un análisis más cuanti¬ 

tativo. 


Validez y confiabilidad Hay dos medidas de desempeño en la construcción de escalas: la va¬ 
lidez y la confiabilidad. El analista de sistemas debe estar consciente de estas medidas. 


íÓ6 
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La validez es el grado en que la pregunta mide lo que el analista pretende medir. Por 
ejemplo, si el propósito del cuestionario es determinar si la organización está lista para 
un cambio trascendental en las operaciones por computadora, ¿las preguntas miden ese 
aspecto? 

La confiabilidad mide la consistencia. Si el cuestionario se aplica una vez y a continua¬ 
ción se aplica nuevamente bajo las mismas circunstancias y en ambos casos se obtienen los 
mismos resultados, se dice que el instrumento tiene consistencia externa. Si el cuestionario 
contiene apartados y éstos tienen resultados equivalentes, se dice que el instrumento tie¬ 
ne consistencia interna. Ambos tipos de consistencia, la externa y la interna, son importantes. 

Construcción de escalas La construcción real de escalas es una tarea seria. La construc¬ 
ción negligente de escalas puede originar alguno de los siguientes problemas: 

1. Condescendencia. 

2. Tendencia central. 

3. Efecto de halo. 

La condescendencia es un problema causado por encuestados que califican a la ligera. 
Un analista de sistemas puede evitar el problema de la condescendencia moviendo la cate¬ 
goría "promedio" a la izquierda (o derecha] del centro. 

La tendencia central es un problema que ocurre cuando los encuestados califican todo 
como promedio. El analista puede mejorar la escala (1} haciendo más pequeñas las diferen¬ 
cias en los dos extremos, (2] ajustando la fuerza de los descriptores o [3] creando una esca¬ 
la con más puntos. 

El efecto de halo es un problema que surge cuando la impresión que se genera en una 
pregunta influye en la próxima pregunta. Por ejemplo, si usted está evaluando a un empleado 
sobre quien tiene una impresión muy favorable, podría darle una calificación alta en cada 
categoría o característica, sin tomar en cuenta si es un punto fuerte del empleado. La solu¬ 
ción es poner una característica y varios empleados en cada página, en lugar de un emplea¬ 
do y varias características en una página. 


DISEÑO DE CUESTIONARIOS 

Muchos de los mismos principios que se aplican al diseño de formularios para la captura 
de datos (que se verá en el capítulo 12] también son importantes aquí. A pesar de que el 
propósito de un cuestionario es recopilar información sobre actitudes, creencias, comporta¬ 
miento y características cuyo impacto puede alterar sustancialmente el trabajo de los usua¬ 
rios, los encuestados no siempre muestran interés en responder. Recuerde que, en conjunto, 
los miembros de una organización a menudo reciben demasiadas encuestas, muchas de las 
cuales están mal planteadas y son triviales. 

Un cuestionario bien diseñado puede ayudar a superar parte de esta reticencia a res¬ 
ponder. A continuación mencionamos algunas reglas para diseñar un buen cuestionario: 

1. Deje bastante espacio en blanco. 

2. Proporcione suficiente espacio para escribir las respuestas. 

3. Facilite a los encuestados que marquen con claridad sus respuestas. 

4. Mantenga un estilo consistente. 

Cuando diseñe cuestionarios para la Web, aplique las mismas reglas que utilice al dise¬ 
ñar cuestionarios impresos. La mayoría de los paquetes de software le permiten insertar al¬ 
guno de los formatos de captura de datos más comunes que se muestran en la figura 4.13. 
Las cuatro reglas anteriores deben ayudarle a conseguir una mejor tasa de respuestas al 
cuestionario. 


El orden de las preguntas No hay una manera de ordenar las preguntas del cuestionario 
que se considere como la mejor. Una vez más, conforme ordene las preguntas, debe pensar 
en los objetivos que persigue con el cuestionario y a continuación determinar la función de 
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EL CUESTIONARIO INSOPORTABLE 


"Voy a caer en una depresión o por lo menos en una pequeña crisis 
nerviosa si alguien no descifra esto pronto", dice Penny Stox, gerente de 
Carbón, Carbón, & Rippy, una importante empresa de corretaje. Penny 
está sentada ante una mesa de conferencias, frente a usted y dos de sus 
ejecutivos de cuenta más productivos, Bill Lowe y Sal Hy. Todos se en¬ 
cuentran dándole vueltas a las respuestas a un cuestionario que ha sido 
distribuido entre los ejecutivos de cuenta de la empresa, el cual se 
muestra en la figura 4.C1. 

"Necesitamos una bola de cristal para entender esto", vociferan Bill 
y Sal al mismo tiempo. 

"Tal vez refleja alguna clase de ciclo optimista, o algo así”, dice 
Penny mientras lee algunas de las respuestas. "En fin, ¿quién diseñó es- • 
te enredo?" 


"Rich Kleintz", responden Bill y Sal al unísono. 

"Bien, como pueden ver, esto no nos sirve para nada", exclama 
Penny. 

Penny y su personal están inconformes con las respuestas que han 
recibido en el cuestionario insoportable, y consideran que éstas reflejan 
de manera poco realista la cantidad de información que necesitan los 
ejecutivos de cuenta. En un párrafo, indique por qué están oc'fuiendo 
estos problemas. En una hoja separada, cambie la escala de las pregun¬ 
tas para evitar estos problemas. 
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cada pregunta en la consecución de sus objetivos. También es importante considerar el 
cuestionario desde el punto de vista del encuestado. Algunos lincamientos para ordenar las 
preguntas son: 

1. Colocar primero las preguntas más importantes para los encuestados. 

2. Agrupar los elementos de contenido similar. 

3. Incorporar primero las preguntas menos polémicas. 

Usted necesita que los encuestados se sientan lo más cómodos e interesados posible con las 
preguntas que les haga, sin que los abrume algún tema en particular. 


APLICACIÓN DE CUESTIONARIOS 

Encuestados La decisión sobre quién recibirá el cuestionario se toma en conjunto con la 
tarea de establecer los objetivos que se persiguen con los resultados del mismo. El muestreo, 
que se explica en el capítulo 5, ayuda al analista de sistemas a determinar la clase de repre¬ 
sentación que se necesita y el tipo de encuestados que deben recibir el cuestionario. 

Los destinatarios a menudo son escogidos como representativos debido a su jerarquía, 
tiempo de servicio en la compañía, deberes, o interés especial en el sistema actual o pro¬ 
puesto. Asegúrese de incluir suficientes encuestados para conseguir una muestra razonable 
en caso de que algunos cuestionarios no sean devueltos o algunas hojas de respuestas sean 
completadas incorrectamente y tengan que desecharse. 

Métodos para aplicar el cuestionario El analista de sistemas tiene varias opciones para 
aplicar el cuestionario, y el método de administración es a menudo determinado por el esta¬ 
do de la empresa. Entre las opciones para aplicar el cuestionario se encuentran las siguientes: 

1. Citar al mismo tiempo a todos los encuestados. 

2. Entregar personalmente los cuestionarios en blanco y recogerlos cuando estén ter¬ 
minados. 

3. Permitir a los encuestados que llenen el cuestionario por sí mismos en su trabajo y que 
lo dejen en una caja colocada en algún punto central. 

4. Mandar por correo los cuestionarios a los empleados de las sucursales e indicarles una 
fecha límite, instrucciones y enviarles sobres con envío prepagado para que devuelvan 
los cuestionarios llenos. 

5. Aplicar el cuestionario a través de correo electrónico o la Web. 



RECOPILACIÓN DE INFORMACIÓN: MÉTODOS INTERACTIVOS 









y los spas de Global Health'? 


Gracias por responder este cuestionario. 


Í poc favor** 
á : mejorar/sacl 
.formularlo; 


H^^^DPORTUNIDAD DE CONSULTORÍA 4.5 


ORDEN EN LA CORTE 


"Yo amo mi trabajo", dice Tennys, empezando la entrevista con una 
volea. "Esto es muy parecido a un juego. Mantengo la vista en la pelota y 
nunca miro hacia atrás", continúa. Tennyson "Tennys" Courts es gerente 
de Global Health Spas, Inc., que tiene spas dedicados a la salud y la re¬ 
creación en todo el mundo. 

"Ahora que he terminado mi maestría en administración de empre¬ 
sas, me siento como si estuviera en la cima del mundo con Global", dice 
Tennys. "Realmente creo que puedo ayudara este equipo a organizar sus 
computadoras y sus spas." 

Tennys intenta ayudar al grupo de sistemas del que usted está a car¬ 
go, el cual desarrolla un sistema que será utilizado por sus 80 filiales 


(en las cuales cada grupo maneja su propia documentación). "¿Te puedo 
dejar esto?", pregunta a Terri Towell, miembro de su equipo de analistas de 
sistemas. "Es un cuestionario que diseñé para distribuir entre los geren¬ 
tes de todos los spas." 

Alguna vez una buena jugadora, Terri le dice a Tennys que le agrada¬ 
ría echarle un vistazo ai formulario. Sin embargo, al regresar a la oficina, 
Terri le deja a usted la responsabilidad. Critique sistemáticamente la téc¬ 
nica de Tennys como se muestra en la figura 4.C2, y explíquele punto por 
punto lo que necesita un cuestionario para ser inigualable con un formulario 
ganador. Con fundamento en su crítica, indíquele a Tennys lo que debe ha¬ 
cer para reescribir el formulario como encuesta de correo electrónico. 
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Cuestionario desarrollado por Tennys Courts para los gerentes de spas de ÍGIobal Health. 


Cada uno de estos cinco métodos tiene ventajas y desventajas. El más común es per¬ 
mitir que los encuestados llenen el cuestionario por sí mismos en el momento que lo pre¬ 
fieran. Las tasas de respuesta con este método son un poco más bajas que con los demás 
métodos, porque la gente olvida el formulario, lo pierde o lo ignora intencionalmente. No 
obstante, la contestación del cuestionario por parte de los encuestados en el momento que 
lo prefieran les permite sentir que su anonimato está garantizado y dar como resultado res¬ 
puestas menos cautelosas que las de otros encuestados. Las encuestas por correo electrónico 
y la Web entran en la categoría de cuestionarios resueltos por los usuarios en el momento 
que lo prefieran. 
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La aplicación electrónica del cuestionario, vía el correo electrónico o colocado en la 
Web, constituye una manera de llegar rápidamente a los usuarios actuales del sistema. Los 
costos de duplicación son mínimos. Además, el encuestado puede responder cuando lo pre¬ 
fiera y sus respuestas se pueden recopilar automáticamente y almacenar por medios elec¬ 
trónicos. Algunos tipos de software permiten al encuestado empezar a responder una en¬ 
cuesta, guardar sus respuestas y regresar a terminarlas si tuvo que interrumpir el proceso. Es 
posible enviar recordatorios a los encuestados, a través de correo electrónico, de manera fácil 
y económica, al igual que notificaciones al analista con la fecha en que el encuestado haya 
abierto el mensaje de correo electrónico. Algunos tipos de software ya convierten los datos 
del correo electrónico en tablas de datos que se utilizan en software de hoja de cálculo o de 
análisis estadístico. 

Los estudios muestran que los encuestados tienen disposición para responder pregun¬ 
tas a través de Internet sobre temas muy delicados. Así, preguntas que sería muy difícil 
plantear en persona acerca de problemas de sistemas podrían responderse fácilmente a tra¬ 
vés de una encuesta en la Web. 



RESUMEN 

Este capítulo abarca tres de los métodos interactivos clave para recopilar información que 
puede utilizar el analista de sistemas: las entrevistas, JAD y los cuestionarios. Durante el 
proceso de la entrevista con los tomadores de decisiones de la organización, que es un mé¬ 
todo utilizado por los analistas de sistemas para recopilar datos sobre los requerimientos de 
información, los analistas escuchan metas, sentimientos, opiniones y procedimientos infor¬ 
males. También venden el sistema durante las entrevistas. Las entrevistas son diálogos de 
preguntas y respuestas entre dos personas, planeados de antemano. El analista se vale de la 
entrevista para desarrollar su relación con un cliente, observar el lugar de trabajo y para recopi¬ 
lar datos relacionados con los requerimientos de información. Aunque el correo electrónico 
puede usarse para preparar al entrevistado planteándole preguntas previas a una reunión, por 
lo general las entrevistas deben realizarse en persona y no de manera electrónica. 

Hay cinco pasos que deben realizarse para preparar la entrevista: 

1. Leerlos antecedentes. 

2. Establecer los objetivos de la entrevista. 

3. Decidir a quién entrevistar. 

4. Preparar al entrevistado. 

5. Decidir el tipo de preguntas y la estructura. 

Hay dos tipos básicos de preguntas: abiertas o cerradas. Las preguntas abiertas permi¬ 
ten al entrevistado usar todas las opciones de respuesta. Las preguntas cerradas limitan las 
opciones de respuesta posibles. Los sondeos o preguntas de seguimiento pueden ser abier¬ 
tos o cerrados, pero piden al encuestado una respuesta más detallada. 

Las entrevistas pueden estructurarse de tres maneras básicas: pirámide, embudo o 
diamante. Las estructuras de pirámide empiezan con preguntas cerradas y detalladas y fi¬ 
nalizan con preguntas más amplias y generales. Las estructuras de embudo empiezan con 
preguntas abiertas y generales y a continuación pasan a preguntas cerradas más específicas. 
Las estructuras con forma de diamante combinan las fortalezas de las otras dos estructuras, 
pero toman muchos más tiempo para realizarse. Hay ventajas y desventajas involucradas 
en la decisión de cuan estructuradas hacer las preguntas de la entrevista y las secuencias de 
preguntas. 

Para reducir el tiempo y costo de las entrevistas personales, los analistas podrían consi¬ 
derar como una alternativa el diseño conjunto de aplicaciones. Con JAD, los analistas 
pueden examinar los requerimientos y diseñar una interfaz de usuario de manera conjunta 
con los usuarios. La evaluación cuidadosa de la cultura particular de una organización ayu¬ 
dará al analista a determinar si JAD es una alternativa adecuada. 
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ISIIIS; 


ON HYPEROASE® 



"Para este momento tal vez ya se dio cuenta de que en MRE no a todos les agrada llenar 
cuestionarios. Tenemos la impresión de que nosotros recibimos más cuestionarios que la 
mayoría de las organizaciones. Creo que es porque muchos de los empleados, sobre todo 
aquellos de la vieja Unidad de Capacitación, valoran las contribuciones de los datos de cues¬ 
tionarios en nuestro trabajo con los clientes. Cuando examine el cuestionario que distribuyó 
Snowden, tal vez usted no sólo deseará ver los resultados sino también criticarlo desde un 
punto de vista de métodos. Siempre creo con firmeza que podemos mejorar nuestro desem¬ 
peño interno para que en el futuro podamos servir mejor a nuestros clientes. La próxima 
vez que elaboremos un cuestionario, nos gustaría mejorar tres cosas: la confiabilidad de los 
datos, la validez de los datos y la tasa de respuesta que recibamos." 


PREGUNTAS DE HYPERCASE 

1. ¿Qué evidencia de cuestionarios ha encontrado en MRE? Especifique qué ha encontra¬ 
do y dónde. 

2. Dé su opinión sobre el cuestionario que circuló Snowden. ¿Qué se le puede hacer para 
mejorar su confiabilidad, validez y tasa de respuesta? Proporcione tres sugerencias 
prácticas. 

3. Escriba un cuestionario breve para dar seguimiento a algunos aspectos que aún no en¬ 
tienda del todo respecto a la fusión entre Management Systems y la Unidad de Capaci¬ 
tación de MRE. Asegúrese de tomar en cuenta todos los lincamientos para diseñar un 
buen cuestionario. 

4. Rediseñe el cuestionario que escribió en la pregunta 3 para que pueda usarse como en¬ 
cuesta en la Web. 



Mediante los cuestionarios, los analistas de sistemas pueden recopilar datos sobre las 
actitudes, creencias, comportamiento y características de las personas importantes de la or¬ 
ganización. Los cuestionarios son útiles si los miembros de la organización están dispersos 
en diversas ubicaciones, muchas personas están involucradas en el proyecto de sistemas, 
se requiere trabajo de investigación antes de recomendar alternativas, o hay necesidad de 
detectar problemas antes de que se realicen las entrevistas. 

Una vez que se establecen los objetivos del cuestionario, el analista puede empezar 
a redactar preguntas abiertas o cerradas. La elección del vocabulario es sumamente im¬ 
portante y debe reflejar el lenguaje de los miembros de la organización. Las preguntas 
deben ser sencillas, específicas, cortas, libres de prejuicios, no condescendientes, técnica¬ 
mente precisas, dirigidas a quienes puedan responderlas y escritas con un nivel de lectura 
apropiado. 

El escalamiento es el proceso de asignar números u otros símbolos a un atributo o ca¬ 
racterística. El analista de sistemas podría requerir el uso de escalas para medir las actitudes 
o características de los encuestados o para que éstos actúen como jueces del tema de los 
cuestionarios. 

Por lo general, los analistas de sistemas utilizan una escala nominal o una de intervalos 
y necesitan tomar en cuenta la validez y la confiabilidad. Validez significa que el cuestiona¬ 
rio mida lo que el analista de sistemas requiera medir. La confiabilidad refleja si los resulta¬ 
dos son consistentes. Al construir escalas, los analistas deben tener cuidado para evitar pro¬ 
blemas como la condescendencia, tendencia central y el efecto de halo. 

El control consistente del formato y el estilo del cuestionario puede dar como resulta¬ 
do una mejor tasa de respuesta. El diseño de las encuestas para Web puede estimular res- 


ANALISiS DE LOS REQUERIMIENTOS DE INFORMACION 






puestas consistentes al incluir botones de opción, menús desplegables y cuadros de texto 
desplazables para plantear preguntas abiertas y cerradas. Además, la clasificación y agrupa¬ 
ción lógicas de las preguntas es importante para facilitar a los encuestados la comprensión 
del cuestionario. Las encuestas se pueden aplicar de diversas maneras, incluyendo (sin limi¬ 
tarse a] medios electrónicos como el correo electrónico o la Web, o con la presencia del ana¬ 
lista en un grupo de usuarios. 


PALABRAS Y FRASES CLAVE 


botón de opción 
casilla de verificación 
condescendencia 
confiabilidad 

cuadro de texto desplazable 
cuestionario 

diseño conjunto de aplicaciones (JAD) 

efecto de halo 

encuestados 

escala de intervalos 

escala nominal 

estructura de diamante 

estructura de embudo 


estructura de pirámide 
menú desplegable 
metas del entrevistado 
opiniones del entrevistado 
preguntas abiertas 
preguntas cerradas 
preguntas cerradas bipolares 
procedimientos informales 
sentimientos del entrevistado 
sondeos 

tendencia central 
validez 


PREGUNTAS DE REPASO 

1. ¿Qué tipos de información debe buscarse en las entrevistas? 

2. Mencione los cinco pasos en la preparación de una entrevista. 

3. Defina lo que significan las preguntas abiertas de una entrevista. Mencione ocho bene¬ 
ficios y cinco desventajas de usarlas. 

4. ¿Cuándo es apropiado el uso de preguntas abiertas en una entrevista? 

5. Defina lo que quiere decirse con preguntas cerradas de una entrevista. Mencione seis 
beneficios y cuatro desventajas de usarlas. 

6. ¿Cuándo es apropiado el uso de preguntas cerradas en una entrevista? 

7. ¿Qué es una pregunta de sondeo? ¿Cuál es el propósito de utilizar preguntas de sondeo 
en las entrevistas? 

8. Defina el significado de estructura de pirámide. ¿Cuándo es útil emplearla en las en¬ 
trevistas? 

9. Defina el significado de estructura de embudo. ¿Cuándo es útil emplearla en las en¬ 
trevistas? 

10. Defina el significado de estructura de diamante. ¿Cuándo es útil emplearla en las en¬ 
trevistas? 

11. Defina el diseño conjunto de aplicaciones [JAD]. 

12. Liste las situaciones que justifican el uso de JAD en lugar de las entrevistas personales 
en la organización. 

13. Mencione los beneficios potenciales de usar el diseño conjunto de aplicaciones. 

14. Liste las tres desventajas potenciales de usar JAD como una alternativa a las entrevistas 
personales. 

15. ¿Qué tipos de información busca el analista de sistemas a través del uso de cuestiona¬ 
rios o encuestas? 

16. Mencione cuatro situaciones que hacen apropiado el uso de cuestionarios. 

17. ¿Cuáles son los dos tipos básicos de pregunta que se usan en los cuestionarios? 

18. Mencione dos razones por las cuales un analista de sistemas debería utilizar una pre¬ 
gunta cerrada en un cuestionario. 
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19. Mencione dos razones por las cuales un analista de sistemas debería usar una pregunta 
abierta en un cuestionario. 

20. ¿Cuáles son los siete lincamientos para elegir el lenguaje del cuestionario? 

21. Defina el significado de escalamiento. 

22. ¿Cuáles son los dos tipos de información o escalas más utilizados por los analistas de 
sistemas? 

23. ¿Para qué se utilizan las escalas nominales? 

24. Dé un ejemplo de escala de intervalos. 

25. ¿Cuándo debe usar escalas de intervalos el analista? 

26. Defina qué es la confiabilidad en la construcción de escalas. 

27. Defina qué es la validez en la construcción de escalas. 

28. Mencione tres problemas que pueden ocurrir debido a la negligencia en la construcción 
de escalas. 

29. Mencione cuatro acciones que se pueden tomar para asegurar que el formato del cues¬ 
tionario propiciará una buena tasa de respuesta. 

30. ¿Qué preguntas deben ponerse primero en el cuestionario? 

31. ¿Por qué deben agruparse las preguntas sobre temas similares? 

32. ¿Cuál es el lugar apropiado para colocar las preguntas polémicas? 

33. Mencione cinco métodos para la aplicación de cuestionarios. 

34. ¿Qué consideraciones son necesarias cuándo los cuestionarios se aplican mediante 
Internet? 


PROBLEMAS 

1. Como parte de su proyecto de análisis de sistemas para actualizar las funciones de 
contabilidad automatizadas de Chronos Corporation, un fabricante de relojes digita¬ 
les, usted entrevistará a Harry Straiter, el jefe de contabilidad. Redacte de cuatro a seis 
objetivos de la entrevista que incluyan su uso de las fuentes de información, los forma¬ 
tos de información, la frecuencia con que toma decisiones, las cualidades que desea de 
la información y su estilo de toma de decisiones. 

a. En un párrafo, mencione cómo se acercará a Harry para preparar una entrevista. 

b. Indique cuál estructura escogerá para esta entrevista. ¿Por qué? 

c. Harry tiene tres subordinados que también usan el sistema. ¿También los entrevis¬ 
taría? ¿Por qué sí o por qué no? 

d. Redacte tres preguntas abiertas que mandará por correo electrónico a Harry antes 
de su entrevista. Explique por qué es preferible realizar una entrevista en persona 
en lugar de vía el correo electrónico. 

2. A continuación se mencionan cinco preguntas redactadas por uno de los miembros de 
su equipo de análisis de sistemas. Su entrevistada es gerente local de LOWCO, una su¬ 
cursal de una cadena de tiendas de descuento que le ha pedido a usted que trabaje en 
un sistema de información gerencial que suministre información de inventarios. Revise 
estas preguntas para su compañero de equipo. 

1. ¿Cuándo fue la última vez que analizó seriamente su proceso de toma de 
decisiones? 

2. ¿Quiénes son los causantes de problemas en su tienda, es decir, aquellos que 
muestran mayor resistencia a los cambios en el sistema que he propuesto? 

3. ¿Hay alguna decisión acerca de la cual usted necesite más información para 
tomarla? 

4. Usted no tiene problemas graves con el sistema de control de inventarios actual, 
¿no es así? 

5. Dígame un poco sobre los resultados que le gustaría ver. 

a. Vuelva a escribir cada pregunta de tal manera que sea más eficaz para obtener in¬ 
formación. 

b. Ordene sus preguntas en una estructura de pirámide, embudo o diamante, y pón¬ 
gales el nombre de la estructura que haya utilizado. 
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c. ¿Qué lincamientos puede darle al miembro de su equipo para que en el futuro me¬ 
jore las preguntas de una entrevista? Haga una lista con estos lincamientos. 

3. Desde que usted cruzó la puerta, su entrevistado, Max Hugo, ha estado revolviendo 
documentos, mirando su reloj y encendiendo y apagando cigarros. Con base en la ex¬ 
periencia que tiene sobre las entrevistas, usted supone que Max está nervioso porque 
tiene trabajo pendiente. En un párrafo, describa cómo manejaría esta situación para 
que Max ponga toda su atención en la entrevista. (Max no puede reprogramar la entre¬ 
vista para otro día.) 

4. Redacte una serie de seis preguntas cerradas que abarquen el aspecto del estilo para 
tomar decisiones del gerente descrito en el problema 2. 

5. Redacte una serie de seis preguntas abiertas que abarquen el aspecto del estilo para 
tomar decisiones del gerente descrito en el problema 2. 

6. Examine la estructura de entrevista presentada en la secuencia de las preguntas si¬ 
guientes: 

1. ¿Cuánto tiempo ha estado en este puesto? 

2. ¿Cuáles son sus responsabilidades fundamentales? 

3. ¿Qué informes recibe? 

4. ¿Cómo considera las metas de su departamento? 

5. ¿Cómo describiría su proceso de toma de decisiones? 

6. ¿De qué manera podría tener un mejor apoyo este proceso? 

7. ¿Con qué frecuencia toma esas decisiones? 

8. ¿A quién consulta cuando toma una decisión? 

9. ¿Cuál de las decisiones que usted toma es fundamental para el funcionamiento 
de su departamento? 

a. ¿Qué estructura se utiliza? ¿Cómo lo sabe? 

b. Reestructure la entrevista cambiando la secuencia de las preguntas [podría omitir 
algunas si es necesario]. Ponga a las preguntas reorganizadas el nombre de la es¬ 
tructura que haya usado. 

7. El siguiente es el primer informe de una entrevista realizado por uno de los miembros 
de su equipo de análisis de sistemas: "En mi opinión, el resultado de la entrevista fue 
muy bueno. El sujeto me permitió hablar con él durante una hora y media. Me relató 
toda la historia del negocio, que fue muy interesante. El sujeto también mencionó que 
las cosas no han cambiado nada desde que él ha estado con la empresa, hace aproxima¬ 
damente 16 años. Pronto nos reuniremos de nueva cuenta para terminar la entrevista, 
porque no tuvimos tiempo para analizar las preguntas que preparé". 

a. En dos párrafos, evalúe el informe de la entrevista. ¿Qué información esencial 
falta? 

b. ¿Qué información es irrelevante en el informe de la entrevista? 

c. Si lo que se informa ocurrió realmente, mencione tres sugerencias que le haría a su 
compañero de equipo para que realizara una mejor entrevista la próxima vez. 

8. Cab Wheeler es un analista de sistemas recién contratado en su grupo. Cab siempre ha 
creído que los cuestionarios son una pérdida de tiempo. Ahora que usted desarrollará 
un proyecto de sistemas para MegaTrucks, Inc., una empresa de transportes con sucur¬ 
sales y empleados en 130 ciudades, usted desea utilizar un cuestionario para obtener al¬ 
gunas opiniones sobre el sistema actual y el que usted propondrá. 

a. Con base en lo que usted sabe de Cab y MegaTrucks, dé tres razones convincentes 
por las cuales Cab debería utilizar una encuesta para este estudio. 

b. Gracias a sus cuidadosos argumentos, Cab aceptó utilizar un cuestionario pero su¬ 
giere firmemente que todas las preguntas sean abiertas para no limitar a los en- 
cuestados. En un párrafo, convenza a Cab de que las preguntas cerradas también 
son útiles. Asegúrese de señalar las ventajas y desventajas que implica cada tipo de 
pregunta. 

9. "Siempre que vienen consultores, nos dan algún tonto cuestionario que no sirve para 
nada. ¿Por qué no se toman la molestia de personalizarlo, por lo menos un poco?", pre¬ 
gunta Ray Dient, jefe de sistemas de emergencia. Usted está analizando la posibilidad 
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de empezar un proyecto de sistemas con Pohattan Power Company (PPC] de Far Melt- 
way, Nueva Jersey. 

a. ¿Qué pasos seguirá para personalizar un cuestionario estandarizado? 

b. ¿Cuáles son las ventajas de adaptar un cuestionario para una organización en par¬ 
ticular? ¿Cuáles son las desventajas? 

10. Una de las preguntas del borrador del cuestionario de Pohattan Power Company dice: 
He estado con la compañía: 

20 o más años 

10-15 años o más 

5-10 años o más 

menos de un año 

Marque la opción más apropiada. 

a. ¿Qué tipo de escala utiliza el autor de la pregunta? 

b. ¿Qué errores se cometieron en la construcción de la pregunta y cuáles podrían ser 
las posibles respuestas? 

c. Redacte nuevamente la pregunta para obtener resultados más claros. 

d. ¿En qué parte del cuestionario debe colocarse la pregunta que ha redactado? 

11. En el cuestionario de PPC también se encuentra la siguiente pregunta: 

Cuando los clientes residenciales llaman, siempre los mando a nuestro sitio Web para 
que obtengan una respuesta. 

A veces Nunca Siempre Normalmente 

1 2 3 4 

a. ¿Qué tipo de escala pretende ser ésta? 

b. Redacte nuevamente la pregunta y las posibles respuestas para conseguir mejores 
resultados. 

12. La figura 4.EX1 presenta un cuestionario diseñado por una empleado de Green Toe 
Textiles, que se especializa en fabricar calcetines para hombre. Di Wooly redactó el 
cuestionario porque, en su calidad de gerente en las oficinas centrales localizadas en Ju- 




El cuestit?!'o ifá T.'íítoaitMti 
por Di Wooly. 


h„ « mo? S[t|£i;| , ‘ H °'“ 3IM0S ,0S '•*»!! 

b - ¿Con qué frecuencia se h » PUtedora veja? 

c-¿Quién la repara? tíesc ™pone? -—__ 

d - ¿Cuándo fue la -—~~-—- 

m ° ™ Práctica? ¿o e —--._ 

f , M . ¿De qtJS se trató? 7--—_____ 

• ¿Usted utiliza una pantalla - -- —___ eomputo y nadie 

9- ¿Que tan rápido escribe en la r >mpre ^^m^ --—-______ 

h - ¿Cuá ntas personas necesitan PUtat,ora? —____"_____ 
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niper, Tennessee, ella tiene que ver con la compra propuesta e implementación de un 
nuevo sistema de cómputo. 

a. En una oración, dé su opinión sobre cada pregunta. 

b. En un párrafo, dé su opinión sobre el diseño y el estilo en cuanto a espacio en blan¬ 
co, espacio para las respuestas, facilidad para responder, etcétera. 

13. Con base en lo que usted crea que la señorita Wooly intenta conseguir con el cuestio¬ 
nario, redacte y reorganice nuevamente las preguntas (use tanto preguntas abiertas co¬ 
mo cerradas) de forma que se apeguen a las buenas prácticas y produzcan información 
útil para los analistas de sistemas. Indique junto a cada pregunta que redacte si es abier¬ 
ta o cerrada, y explique en una oración por qué la redactó de esa manera. 

14. Rediseñe el cuestionario que redactó para la señorita Wooly en el problema 13 de for¬ 
ma que se pueda utilizar por correo electrónico. Explique en un párrafo los cambios 
que fueron necesarios para adaptarlo a los usuarios de correo electrónico. 

15. Rediseñe el cuestionario que redactó para la señorita Wooly en el problema 13 de for¬ 
ma que se pueda utilizar como encuesta en la Web. Explique en un párrafo los cambios 
que fueron necesarios para adaptarlo a los usuarios de la Web. 


PROYECTOSDEGRUPO 


1. Con los miembros de su grupo, representen una serie de entrevistas con varios usua¬ 
rios del sistema de MaverickTransport. Cada miembro de su grupo debe escoger uno 
de los roles siguientes: presidente de la compañía, director de tecnología de la infor¬ 
mación, despachador, agente de servicio a clientes o camionero. Los miembros del 
grupo que representen los roles de empleados de MaverickTransport tienen que des¬ 
cribir brevemente las responsabilidades de sus puestos, sus metas y sus necesidades 
de información. 

Los miembros restantes del grupo deben desempeñar los roles de analistas de siste¬ 
mas e inventar preguntas de entrevista para cada empleado. Si hay suficientes personas 
en su grupo, se podría asignar un analista para entrevistar a un empleado diferente. 
Quienes representen los roles de analistas de sistemas deben trabajar en conjunto para 
desarrollar preguntas comunes y preguntas específicas para cada empleado individual. 
Asegúrense de incluir preguntas abiertas, cerradas y de sondeo en sus entrevistas. 

MaverickTransport está tratando de cambiar su tecnología obsoleta e inestable por 
tecnología de vanguardia y confiable. La compañía busca deshacerse de las terminales 
tontas conectadas a un mainframe porque quiere usar PCs, y también está interesada 
en un sistema satelital para el rastreo de la carga y los camioneros. Además, la compañía 
tiene interés en encontrar formas de reducir las enormes necesidades de almacena¬ 
miento y de acceso a los problemáticos formularios de varias hojas, escritos a mano, que 
acompañan a cada embarque. 

2. Realice cinco entrevistas en un ejercicio de representación de roles. Si hay más de 10 
personas en su grupo, permite que dos o más analistas hagan preguntas. 

3. Con su grupo, redacte un plan para una sesión de JAD que reemplace a las entrevistas 
personales. Incluya a los participantes relevantes, el escenario sugerido, etcétera. 

4. Usando los datos de la entrevista que obtuvo en el ejercicio de grupo sobre Maverick 
Transport en el proyecto 1, realice una sesión de lluvia de ideas con su grupo para dise¬ 
ñar un cuestionario dirigido a los cientos de camioneros de Maverick Transport. Re¬ 
cuerde que Maverick tiene interés en implementar un sistema satelital para el rastreo 
de la carga y los camioneros. También hay otros sistemas que podrían afectar a los ca¬ 
mioneros. Conforme elaboren el cuestionario, tomen en cuenta el probable nivel edu¬ 
cativo de los camioneros y las restricciones de tiempo que podrían tener para llenar el 
cuestionario. 

5. Usando los datos de la entrevista que obtuvo en el ejercicio de grupo sobre Maverick 
Transport en el proyecto 1, su grupo debe reunirse para diseñar un cuestionario 
orientado al correo electrónico o la Web para encuestar a los 20 programadores de la 
compañía (15 de los cuales fueron contratados el año pasado) sobre sus habilidades, 
ideas para nuevos o mejores sistemas, etc. Conforme elaboren la encuesta para los 
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programadores, consideren lo que han descubierto de los usuarios en las otras entre¬ 
vistas así como la visión que tiene de la compañía el director de tecnología de la in¬ 
formación. 
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ESCUCHAR ORA Y PREGUNTARÉ DESPUÉS 



"He programado entrevistas preliminares con cinco personas importantes. Como tú has es¬ 
tado tan ocupado con Visible Analyst, decidí hacer la primera ronda de entrevistas yo mis¬ 
ma", dice Anna a Chip al comenzar su reunión por la mañana. 

"Por mí está bien", responde Chip. "Sólo avísame cuándo puedo intervenir. ¿A quién 
entrevistarás primero? ¿A Dot?" 

"Supongo que con ella no descubriré nada nuevo", contesta Anna. "Ella es importante 
para que el sistema tenga éxito. Su palabra es ley cuando se trata de decidir si un proyecto 
procede o no". 

"¿A quién más?", pregunta Chip. 

"Veré a quién me recomienda Dot, pero concerté citas con Mike Crowe, el experto de 
mantenimiento; Cher Ware, el especialista de software, y Paige Prynter, el analista financie¬ 
ro de CPU". 

"No olvides a Hy Perteks", dice Chip. 

"De acuerdo. El Centro de Información será importante para nuestro proyecto", dice 
Anna. "Permíteme hablarle y ver cuándo está disponible". 

Después de una breve conversación telefónica con Hy, Anna regresa con Chip. 

"Se reunirá más tarde conmigo", confirma Anna. 

Después de completar sus entrevistas, Anna se sienta ante su escritorio a repasar los re¬ 
súmenes de las entrevistas y los memorandos que se recopilaron durante el verano. Varias 
pilas de documentos se encuentran ordenadamente archivadas en carpetas. 

"Tenemos bastante información", comenta a Chip, "aunque todavía siento que sólo es¬ 
tamos trabajando con la punta del iceberg. Aún desconozco las dificultades de los profeso¬ 
res y del personal de investigación. ¿Hay problemas adicionales de los cuales todavía no nos 
hayamos enterado?" 

Chip interrumpe su tarea de tratar de extraer los puntos importantes para definir los 
problemas. "Me pregunto si debemos hacer más entrevistas, o quizás recopilar más docu¬ 
mentos", dice. 

"¿Pero cuántas entrevistas debemos hacer y a quién debemos entrevistar?", contesta 
Anna. "Supon que entrevistamos a varios miembros del personal y tomamos los resultados 
como base para el nuevo sistema. Podríamos entrevistar a la gente inadecuada y diseñar un 
sistema para satisfacer solamente sus necesidades, dejando de lado problemas importantes 
que la mayoría de los profesores y el personal requieren solucionar". 

"Entiendo lo que tratas de decir", responde Chip. "Quizá debamos diseñar un cuestio¬ 
nario y aplicar una encuesta entre los profesores y el personal de investigación". 

"[Excelente ideal", exclama Anna. "¿Cómo debemos decidir qué preguntas incluir en la 
encuesta?" 

"Hablemos con algunas personas importantes y tomemos los resultados como base de 
la encuesta. Hy Perteks podría ser un buen punto de partida, porque él siempre está en co¬ 
municación con los profesores y el personal. Yo le llamaré y concretaré una reunión", dice 
Chip. 

Chip concertó la reunión para la mañana siguiente. Se sostendría en una sala de confe¬ 
rencias adyacente al Centro de Información. 

"Gracias por reunirse con nosotros a pesar de habérselo pedido en forma tan prematu¬ 
ra", inicia Chip la conversación. "Estamos considerando la posibilidad de encuestar a los 
profesores y al personal de investigación para conseguir información adicional que nos sirva 
para definir algunos aspectos del sistema". 
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"Creo que es una excelente idea", contesta Hy. "También me gustaría averiguar qué ti¬ 
po de software debe estar disponible en el Centro de Información y el tipo de capacitación 
que debemos proporcionar. De igual manera, debe conseguirse información sobre los prin¬ 
cipales tipos de paquetes que se utilizan", continúa Hy. "El software de procesamiento de 
texto es esencial. Debemos averiguar qué paquete prefiere cada usuario e, igualmente im¬ 
portante, la versión del paquete. Sé que muchos utilizan Microsoft Word y otros usan 
WordPerfect. El software de base de datos también varía aunque la mayoría emplea Access. 
Lo mismo ocurre con las hojas de cálculo, donde Excel es el más popular. 

"Otra consideración sería qué tipo de software especializado usan los grupos de profe¬ 
sores", cavila Hy. "Muchos integrantes del departamento de matemáticas utilizan Exp, un 
procesador de texto de matemáticas. Otros utilizan diversos paquetes de software para una 
gran cantidad de cursos. Por ejemplo, la gente del área de ciencias de la información utiliza 
Visible Analyst, pero unos cuantos emplean Visio. También he oído que estamos adquiriendo 
software de biología y astronomía. Y el departamento de arte usa Macs casi exclusivamente. 
Muchos de los profesores se están interesando en gran medida por el software para la cons¬ 
trucción de sitios Web, como Dreamweaver y FrontPage". 

"Aparte de los paquetes de software y sus versiones, ¿qué tipo de información debemos 
recopilar?", pregunta Chip. 

"Me gustaría saber el nivel de conocimientos que tiene cada persona", responde Hy. 
"Sin duda, algunos son principiantes, en tanto que otros tienen un buen conocimiento pero 
no dominan todas las características de un paquete en particular. Algunos son expertos. 
Conocen el software por dentro y por fuera. Me interesan los usuarios principiantes y los in¬ 
termedios, porque debemos ofrecerles una capacitación distinta. También es útil saber quié¬ 
nes son los expertos". 

"¿Hay algo más que consideres que debemos averiguar en la encuesta?", pregunta Chip. 

"La única otra cosa que me preocupa son los problemas que provoquen que un profe¬ 
sor o algún miembro del personal no utilice el software", responde Hy. 

"Qué quieres decir?", pregunta Chip. 

"Bueno, supongan que una persona tiene el software pero éste no se encuentra bien 
instalado o despliega un mensaje, como 'Memoria insuficiente' o 'Este asistente no está ins¬ 
talado" 1 , contesta Hy. "Recientemente tuve algunos problemas similares. Una persona me 
dijo que sólo podía utilizar Access para realizar tareas sencillas porque el programa siempre 
le mandaba un mensaje indicándole que los asistentes no estaban instalados. Resultó que el 
sistema no estaba bien configurado para ejecutarse en una red. Fue muy sencillo corregir 
el problema, [pero estuvo dando dolores de cabeza durante mucho tiempo] Hay un profe¬ 
sor de matemáticas, Rhoda Booke, que constantemente muestra interés por los problemas 
del hardware y el software. Yo la he ayudado varias veces, y ella siempre se muestra amisto¬ 
sa y agradecida. Definitivamente deben entrevistarla". 

"Gracias otra vez por toda tu ayuda", dice Chip. "Después te traeremos los resultados 
de la encuesta". 

Anna consigue una reunión con Rhoda y le explica la naturaleza del proyecto y por qué 
la eligieron como representante de los profesores. La reunión se celebró en una pequeña 
sala de conferencias del departamento de matemáticas. 

"Quisiéramos conocer la opinión de los profesores acerca de los problemas que han en¬ 
contrado con las PCs y el software relacionado con éstas", dice Anna. "Nuestro propósito es 
ofrecer a los profesores los mejores recursos posibles con el mínimo de problemas". 

"Estoy feliz por formar parte de este proyecto", exclama Rhoda. "He estado usando el 
software en mis clases durante cerca de cinco años, [y vaya si ha sido una experiencia de 
aprendizaje! Por fortuna Hy siempre está a la mano. Le he quitado varias horas de su tiem- 
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po, pero bien ha valido la pena el esfuerzo. Me siento mucho más productiva, y los estudian¬ 
tes están usando software que les ayuda a comprender a conciencia el material". 

"Eso es bueno, ¿pero ha estado sufriendo alguna dificultad?", pregunta Chip. 

"Bueno, el principal obstáculo es familiarizarse con el software. Pasé una buena parte 
del verano pasado, cuando no estaba trabajando en mi libro, aprendiendo a usar el software 
para mis clases de álgebra y cálculo. Fue muy interesante, pero me atoré varias veces y tu¬ 
ve que pedir ayuda. Es necesario entender el software para preparar las lecciones y explicar 
a los estudiantes cómo utilizarlo". 

"¿Hay problema al instalar software o hardware?", pregunta Anna. 

"[Oh, sil", exclama Rhoda. "Intenté instalar el software, y todo transcurrió muy bien 
hasta la parte en que la pantalla empezó a pedir información sobre diversos formatos para 
importar archivos gráficos, como PSD y PNG. Yo no sabía lo que significaban esas letras", ríe 
Rhoda. 

"A continuación surgieron problemas de configuración", continúa Rhoda. "Tuve que 
averiguar qué instalar en la red y qué incluir en el disco duro local. Algunas de las compu¬ 
tadoras del laboratorio de estudiantes nos enviaron mensajes de error 'Memoria insuficien¬ 
te', y nos dimos cuenta de que tenían que instalarse que el mínimo de memoria. Los profe¬ 
sores de física tuvieron el mismo problema". 

"¿Hay algún otro asunto que consideres que debamos incluir en nuestra encuesta a los 
profesores y al personal de investigación?", preguntó Chip. 

"Sería útil saber quién está usando el mismo software en diferentes departamentos y el 
software que proporciona cada fabricante. Quizás si compráramos muchos paquetes a un 
fabricante, podríamos conseguir un descuento más grande para el software. El presupuesto 
de software del departamento ya se agotó", dice Rhoda. 

"Gracias por toda tu ayuda", le dice Anna. "Si recuerdas cualquier pregunta adicional 
que debamos incluir en la encuesta, por favor no dudes en llamarnos". 

De vuelta en su oficina, los analistas se dan a la tarea de compilar una lista de los asun¬ 
tos que se incluirán en la encuesta. 

"Definitivamente tenemos que averiguar qué software está en uso y las necesidades de 
capacitación", comenta Anna. "También debemos resolver los problemas que estén ocu¬ 
rriendo". 

"De acuerdo", contesta Chip. "Creo que debemos incluir preguntas sobre los paquetes 
de software, fabricantes, versiones, nivel de conocimiento y aspectos de capacitación. No es¬ 
toy muy seguro sobre cómo obtendremos la información sobre los problemas que están en¬ 
frentando los profesores y el personal. ¿Cómo debemos enfrentar estas cuestiones?" 

"Bueno", responde Anna, "debemos enfocarnos en los aspectos con los cuales estén fa¬ 
miliarizados. Podríamos plantear preguntas acerca del tipo de problemas que están ocu¬ 
rriendo, pero definitivamente no deben ser técnicas. Y en la encuesta no debemos incluir 
preguntas cuyas respuestas podamos buscar fácilmente nosotros, como '¿Quién es el fabri¬ 
cante del software?"'. 

'Ya entiendo", afirma Chip. "Dividamos las preguntas por categorías. Algunas podrían 
ser cerradas y otras abiertas. Ahí está la respuesta de qué estructura utilizar". 



EJERCICIOS 

Los primeros tres ejercicios requieren que usted visite el sitio Web de este libro para obte¬ 
ner el texto de las entrevistas con el personal de CPU (CPU Interviews). 

E-l. Analice las cinco entrevistas. En un párrafo, describa qué tipo de estructura tiene ca¬ 
da entrevista. 
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E-2. Liste cada entrevista, de la 1 a la 5, y a continuación redacte un párrafo para cada una, 
en los cuales mencione sugerencias para que Anna mejore sus entrevistas la próxima 
vez que las realice. 

E-3. Analice las preguntas usadas en las cinco entrevistas. En un párrafo, explique qué ti¬ 
pos de preguntas son y si fueron apropiadas para obtener la información que se nece¬ 
sitaba. 

E-4. De las preocupaciones expresadas en el caso de la CPU anterior, elija las que se po¬ 
drían plantear mejor como preguntas cerradas. 

E-5. De las preocupaciones expresadas en el caso de la CPU anterior, elija las que se po¬ 
drían plantear mejor como preguntas abiertas. 

E-6. Con base en los ejercicios E-4 y E-5, diseñe un cuestionario para enviarlo a los profe¬ 
sores y al personal de investigación. 

E-7. Pruebe su cuestionario pidiendo a otros estudiantes de su clase que lo contesten. Con 
base en la retroalimentación que le den y en su propia capacidad para analizar los da¬ 
tos, modifique su cuestionario. 
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Tan sólo con su presencia en una organización, el analista de sistemas la cambia. Sin embar¬ 
go, los métodos no intrusivos comoelmuestreo, la investigación y la observación del com¬ 
portamiento y el entorno físico de un tomador de decisiones, son menos molestos que otras 
formas de obtenerlos requerimientos de información. Dichos métodos se consideran défi-: 
cientes si sé usan pór sí sólós papá recopilar información. De preferencia, se deben usar en 
conjunto con uno 0 varios de los métodos interactivos que se estudiaron en él capítulo an¬ 
terior. Á esto se le llama enfoque de métodos múltiples. El uso conjunto de los métodos 
interactivos y lós no intrusivos para acercarse a la organización es una práctica inteligente 
que ofrecerá un panorama más completo de los requerimientos de información. 


iUESTREO 

El maestreo es el proceso consistente en seleccionar sistemáticamente elementos répresen- 
tativ'os de una población. Cuando dichos elementos se examinan con cuidado, se da por he¬ 
cho que el análisis revelará información útil de la población en general. .. 

: . i-.' El analista de sistemas debe tomar una decisión sobre dos aspectos importantes. Prime-, 
•; ro, hay una gran cantidad de informes, formularios, documentos de resultados, memorandos 
y sitios Web que han sido creados por los miembros de la organización. ¿A cuáles de éstos 
debe prestar atención el analista de sistemas, y cuáles debe ignorar? 

Segundo, muchísimos empleados pueden ser afectados por el sistema dé información'' 
propuesto. ¿A qué personas debe entrevistar el analista de sistemas, de cuáles débe buscar 
información a través de cuestionarios o a cuáles debe observar en el proceso de ejecución de 
sus roles de tomadores de decisiones 7 : : 


































LA NECESIDAD DE MUESTREO 


Hay muchas razones por las cuales un analista de sistemas tendría que seleccionar una 
muestra representativa de datos para examinarla o personas representativas para entrevis¬ 
tarlas, aplicarles un cuestionario u observarlas. Entre estas razones se incluyen: 

1. Reducir costos. 

2. Acelerar la recopilación de datos. 

3. Mejorar la efectividad. 

4. Reducir la parcialidad. 

Analizar cada pedazo de papel, hablar con todos y leer cada página Web de la organiza¬ 
ción sería demasiado costoso para el analista de sistemas. Copiar los informes, quitarles 
tiempo valioso a los empleados y duplicar encuestas innecesarias produciría un gasto consi¬ 
derable e innecesario.. 

El muestreo ayuda a acelerar el proceso mediante la recopilación de datos selecciona¬ 
dos en lugar de todos los datos de la población entera. Además, el analista de sistemas se 
ahorra el trabajo de analizar los datos de toda la población. 

También la efectividad en la recopilación de los datos es un aspecto importante. El 
muestreo puede ayudar a mejorar la efectividad si se puede obtener la información más 
precisa. Este tipo de muestreo se consigue, por ejemplo, al hablar con menos empleados 
pero haciéndoles preguntas más detalladas. Además, si se entrevistan menos personas, el 
analista de sistemas puede tomarse su tiempo para verificar que no haya datos perdidos o 
incompletos, mejorando así la efectividad de la recopilación de datos. 

Finalmente, es posible reducir la parcialidad en la recopilación de datos mediante el 
muestreo. Por ejemplo, cuando el analista de sistemas entrevista a un ejecutivo de la em¬ 
presa, éste está involucrado con el proyecto, debido a que ya le ha invertido tiempo y qui¬ 
siera que fuera exitoso. Cuando el analista de sistemas pide una opinión sobre una caracte¬ 
rística permanente del sistema de información instalado, el ejecutivo entrevistado podría 
proporcionar una evaluación parcial, debido a que hay pocas posibilidades de cambiar la 
característica. 


DISEÑO DEL MUESTREO 

Un analista de sistemas debe seguir cuatro pasos para diseñar una buena muestra: 

1. Determinar qué datos van a ser recopilados o descritos. 

2. Determinar de qué población se van a tomar muestras. 

3. Escoger el tipo de muestra. 

4. Decidir el tamaño de la muestra. 

Estos pasos se describen con mayor detalle en los apartados siguientes. 

Cómo determinar qué datos van a ser recopilados o descritos El analista de sistemas nece¬ 
sita un plan realista sobre lo que se hará con los datos una vez que se hayan recopilado. Si se 
recopilan, almacenan y analizan datos irrelevantes, sería un desperdicio de tiempo y dinero. 

En este punto los deberes y responsabilidades del analista de sistemas consisten en 
identificar las variables, atributos y los elementos relacionados con los datos que necesitan 
recopilarse en la muestra. Se deben considerar los objetivos del estudio así como el método 
de recopilación de datos [investigación, entrevistas, cuestionarios, observación) que se utili¬ 
zará. Los tipos de información que se pretende recopilar con cada uno de estos métodos se 
discuten con más detalle en este capítulo y los siguientes. 


Cómo determinar de qué población se van a tomar muestras A continuación, el analista 
de sistemas debe determinar la población. Por ejemplo, en el caso de datos reales y concre¬ 
tos, el analista de sistemas tiene que decidir si los últimos dos meses son suficientes para el 
análisis, o si éste requiere un año completo de informes. 
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Del mismo modo, al decidir a quién entrevistar, el analista de sistemas tiene que deter¬ 
minar si la población debe incluir un solo nivel de la organización o todos los niveles, o in¬ 
cluso quizá sea necesario que el analista salga del entorno para incluir las reacciones de 
clientes, vendedores, proveedores o competidores. Estas decisiones se explorarán con más 
detalle en los capítulos sobre entrevistas, cuestionarios y observación. 

Cómo seleccionar el tipo de muestra Como se aprecia en la figura 5.1, el analista de sis¬ 
temas puede utilizar uno de cuatro tipos principales de muestras. Dichos ejemplos son de 
conveniencia, intencional, simple y compleja. Las muestras de conveniencia son irrestrictas 
y no probabilísticas. Por ejemplo, a una muestra se le podría llamar de conveniencia si el 
analista de sistemas publica un aviso en la intranet de la compañía pidiendo a todos los in¬ 
teresados en los nuevos informes del desempeño de las ventas asistir a una reunión el 
martes 12 a la 1 pJVL Obviamente, esta muestra es la más fácil de obtener, pero también es 
la menos confiable. Una muestra intencional se basa en juicios. Un analista de sistemas 
puede escoger un grupo de personas que parezca conocedor e interesado en el nuevo siste¬ 
ma de información. Aquí el analista de sistemas basa la muestra en criterios [el conocimien¬ 
to y el interés en el nuevo sistema), pero sigue siendo una muestra no probabilística. Por lo 
tanto, el muestreo intencional sólo es moderadamente confiable. Si decide realizar una 
muestra aleatoria simple, necesita obtener una lista numerada de la población para cercio¬ 
rarse de que cada documento o persona en la población tienen la misma oportunidad de ser 
seleccionados. Por lo regular este paso no es práctico, sobre todo cuando el muestreo se rea¬ 
liza con documentos e informes. Las muestras aleatorias complejas más apropiadas para 
el analista de sistemas son: 1] el muestreo sistemático, 2} el muestreo estratificado y 3} el 
muestreo por conglomerados. 

En el método más simple de muestreo probabilístico, el muestreo sistemático, el analis¬ 
ta de sistemas podría, por ejemplo, escoger a cada n-ésima persona de una lista de empleados 
de una compañía. Sin embargo, este método tiene ciertas desventajas. No sería conveniente 
para seleccionar todos los nésimos días para una muestra debido al potencial problema de la 
periodicidad. Además, el analista de sistemas no usaría este enfoque si la lista fuera ordena¬ 
da (por ejemplo, una lista de bancos del más pequeño al más grande), debido a que se po¬ 
dría producir una muestra sesgada. 

Quizás las muestras estratificadas son las más importantes para el analista de sistemas. 
La estratificación es el proceso de identificar las subpoblaciones, o estratos, y después se¬ 
leccionar objetos o personas para el muestreo en estas subpoblaciones. Con frecuencia, este 
proceso es fundamental si el analista de sistemas desea recopilar eficazmente los datos. Por 
ejemplo, si necesita obtener opiniones de un gran número de empleados de los diferentes 
niveles de la organización, el muestreo sistemático podría seleccionar un número despro¬ 
porcionado de empleados del nivel de control operativo. Una muestra estratificada balan¬ 
cearía esta situación. La estratificación también es apropiada cuando el analista de sistemas 
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necesita utilizar distintos métodos para recopilar datos de diferentes subgrupos. Por ejemplo, 
tal vez quisiera usar una encuesta para recopilar datos de los gerentes de nivel medio, pero 
quizás prefiera usar las entrevistas personales para recopilar datos similares de ejecutivos. 

Algunas veces el analista de sistemas debe seleccionar un grupo de documentos o per¬ 
sonas para estudiarlo. Este proceso se conoce como muestreo por conglomerados. Suponga 
que una organización tiene 20 centros de asistencia técnica dispersos por el país. Tal vez us¬ 
ted necesite seleccionar uno o dos de estos centros de asistencia técnica bajo la suposición 
de que son representativos de todos los demás. 

Cómo decidir el tamaño de la muestra Obviamente, si todos en la población vieran el 
mundo de la misma forma o si cada uno de los documentos contuviera exactamente la mis¬ 
ma información que los demás, sería suficiente un tamaño de uno para la muestra. Puesto 
que éste no es el caso, es necesario establecer un tamaño de muestra mayor que uno pero 
menor que el tamaño mismo de la población. 

Es importante recordar que en el muestreo es de mayor importancia el número abso¬ 
luto que el porcentaje de la población. Podemos obtener resultados satisfactorios con un 
muestreo de 20 personas de 200 o con uno de 20 de 2,000,000. 


DECISIÓN DEL TAMAÑO DE LA MUESTRA 

Con frecuencia, el tamaño de la muestra depende del costo involucrado o del tiempo re¬ 
querido por él analista de sistemas, o incluso del tiempo que tengan las personas de la orga¬ 
nización. Esta subsección proporciona al analista de sistemas algunos lincamientos para de¬ 
terminar el tamaño de la muestra requerido bajo condiciones ideales, por ejemplo, para 
determinar qué porcentaje de formularios contestados contiene errores, o en otro caso, qué 
proporción de personas entrevistar. 

El analista de sistemas debe seguir siete pasos, algunos de los cuales son juicios subjeti¬ 
vos, para determinar el tamaño de la muestra requerido: 

1. Determinar el atributo (en este caso, el tipo de errores que se buscará). 

2. Localizar la base de datos o informes en los cuales se puede encontrar el atributo. 

3. Examinar el atributo. Calcular p, la proporción de población que tiene el atributo. 

4. Tomar la decisión subjetiva con respecto a la estimación del intervalo aceptable, i. 

5. Seleccionar el nivel de confianza y buscar el coeficiente de confianza (valor z) en una 

tabla. 

6. Calcular cr p , el error estándar de la proporción, de la siguiente manera: 

°> = í’ 

Determinar el tamaño de la muestra necesario, n, con la fórmula siguiente: 

n_P ( l- p) j. ! 

¡i — T ti 

arp 

Por supuesto, el primer paso es determinar el atributo del cual se tomará la muestra. Una 
vez hecho esto, tiene que averiguar en dónde están almacenados los datos, quizás en una ba¬ 
se de datos, en un formulario o en un informe. 

Es importante calcular p, la proporción de población que tiene el atributo, para esta¬ 
blecer el tamaño apropiado de la muestra. Muchos libros de texto sobre análisis de sistemas 
sugieren utilizar un heurístico de 0.25 para p¡\ — p). Por lo regular de este valor resulta un 
tamaño de muestra mayor que el necesario debido a que 0.25 es el valor máximo del>(l — -p), 
que sólo ocurre cuando p = 0.50. Cuando p = 0.10, tal como en la mayoría de los casos, 
p(l -p) se vuelve 0.09, dando como resultado un tamaño de muestra más pequeño. 

Los pasos 4 y 5 son decisiones subjetivas. La estimación del intervalo aceptable de 
+0.10 significa que usted está dispuesto a aceptar un error de no más de 0.10 en cualquier 
dirección de la proporción real, p. El nivel de confianza, por ejemplo 95 por ciento, es el 
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grado de certeza deseado. Una vez que se elige dicho nivel, se puede buscar el coeficiente 
de confianza (también conocido como valor z) en una tabla similar a la que se muestra en 
la figura 5.2. 

Los pasos 6 y 7 completan el proceso tomando los parámetros encontrados o estableci¬ 
dos en los pasos 3 a 5 e introduciéndolos en dos ecuaciones para determinar finalmente el 
tamaño de la muestra requerido. 

Ejemplo 

Los pasos anteriores se pueden describir mejor mediante un ejemplo. Suponga que 
la A. Sembly Company, un fabricante a gran escala de productos de estantería, le 
pide que determine qué porcentaje de pedidos contiene errores. Usted acepta este 
trabajo y realiza los pasos siguientes: 

1. Determina que buscará los pedidos que contienen errores en nombres, direc¬ 
ciones, cantidades o en números de modelo. 

2. Localiza copias de los formularios de pedido de los últimos seis meses. 

3. Examina algunos de los formularios de pedido y concluye que solamente 5 
por ciento (0.05) contiene errores. 

4. Toma una decisión subjetiva respecto a que la estimación del intervalo acepta¬ 
ble será +0.02. 

5. Selecciona un nivel de confianza de 95 por ciento. Busca el coeficiente de con¬ 
fianza (valor z) en la figura 5.2. El valor z es igual a 1.96. 

6. Calcula ap de la siguiente manera: 

"'■«■uü* 00102 

7. Determina el tamaño de la muestra necesario, n, de la siguiente manera: 


1 , 0-05(0.95) -1- j = 45S 

a\ (0.0102)(0.0102) 

La conclusión, entonces, es establecer en 458 el tamaño de la muestra. Obvia¬ 
mente, un nivel de confianza mayor o una estimación del intervalo aceptable más 
pequeña requerirían un tamaño de muestra más grande. Si mantenemos la misma 
estimación del intervalo aceptable pero aumentamos el nivel de confianza a 99 
por ciento (con un valor z de 2.58), el tamaño necesario de la muestra será 1,827, 
una cifra mucho más grande que la de 458 que decidimos originalmente para la 
muestra. 
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ANALISIS DE DOCUMENTOS CUANTITATIVOS 


En todas las empresas existen muchos documentos cuantitativos disponibles para su inter¬ 
pretación, y entre ellos se incluyen informes usados para la toma de decisiones, informes de 
desempeño, registros y una variedad de formularios. Todos estos documentos tienen un pro¬ 
pósito y un público específicos a los cuales van dirigidos. 

Informes usados para la toma de decisiones Un analista de sistemas necesita obtener al¬ 
gunos de los documentos que se usan para dirigir un negocio. Estos documentos son a me¬ 
nudo los informes escritos referentes al estado del inventario, ventas o producción. Muchos 
de estos informes no son complejos, pero sirven principalmente como una retroalimenta- 
ción para tomar medidas inmediatas. Por ejemplo, un informe de ventas puede resumir la 
cantidad vendida y el tipo de ventas. Además, los informes de ventas podrían incluir resul¬ 
tados gráficos que comparen ingresos y ganancias de un número determinado de periodos. 
Tales informes ayudan al tomador de decisiones a identificar fácilmente las tendencias. 

Los informes de producción incluyen costos recientes, inventario actual, mano de obra 
reciente e información de las instalaciones. Aparte de estos informes clave, los tomadores de 
decisiones usan muchos informes resumidos para extraer información histórica, identificar 
eventos excepcionales y obtener un panorama estratégico de los planes de la organización. 

Informes de desempeño La mayoría de estos informes reflejan el desempeño real versus 
el desempeño deseado. Una función importante de los informes de desempeño es evaluar la 
dimensión de la brecha entre el desempeño real y el deseado. También es importante poder 
determinar si la brecha se está extendiendo o se está contrayendo como una tendencia ge¬ 
neral en cualquier área de desempeño que se esté midiendo. En la figura 5.3 se muestra una 
clara mejora en el desempeño de las ventas durante dos de los tres meses. El analista necesi¬ 
tará determinar si el desempeño medido es accesible y adecuado para las áreas importantes 
de la organización. 



Un informe de desempeño 
que muestra una mejora. 
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Un registro de pago llenado 
manualmente. 
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'$C£p> 


Wa 





Registros Los registros proporcionan actualizaciones periódicas de lo que ocurre en el 
negocio. Si un archivista cuidadoso actualiza sin retrasos el registro, este último puede pro¬ 
porcionar información muy útil al analista. La figura 5.4 es un registro de pago, llenado a 
mano, del alquiler de un departamento. Hay varias formas en las que el analista puede revi¬ 
sar un registro: 

1. Buscar errores en cifras y sumas totales. 

2. Buscar oportunidades para mejorar el diseño del formulario de registro. 

3. Observar el número y tipo de las transacciones. 

4. Buscar puntos donde la computadora pueda simplificar el trabajo (es decir, cálculos y 
otra manipulación de los datos]. 

Formularios de captura de datos Antes 3 de que empiece a cambiar los flujos de informa¬ 
ción en la organización, necesita entender el sistema actual. Usted o alguno de los miem¬ 
bros de su equipo podrían dedicarse a recolectar y catalogar una copia en blanco de cada 
formulario (oficial o extraoficial] que esté en uso. (A veces las empresas tienen una persona 
encargada de administrar los formularios, y esa persona sería su primera fuente para buscar 
los formularios en uso.] 

Los formularios en blanco, junto con sus instrucciones de llenado y distribución, se 
pueden comparar con los formularios contestados para averiguar si alguno de sus elementos 
de datos queda regularmente sin respuesta; para saber si las personas a quienes se supone 
que deben entregarse los formularios realmente los reciben; y para determinar si éstas siguen 
procedimientos estandarizados al usarlos, almacenarlos y desecharlos. Recuerde imprimir 
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OPORTUNIDAD DE CONSULTDRÍA 5.2 


UNA ROSA POR CUALQUIER OTRO NOMBRE,. 
Q...CALI D AD iJL - NO^ CANTIDADES 


"Creo que tenemos todo lo que necesitamos. Hetomado muestrasde 
estados financieros, cifras de ventas dé cada sucursal, las pérdidas de ca¬ 
da tienda —lo tenemos todo—.Con todos estos números, deberíamos in¬ 
geniárnoslas para mantener a Fields a la vanguardia del negocio de las 
flores. Incluso le podemos mostrar al propio Seymour Fields cómo lograr 
esto con su nuevo sistema de cómputo”, dice Rod Golderi, un analista de 
sistemas novato que trabaja para un grupo consultor no muy grande. 

La empresa, bajo la vigilancia de su analista de sistemas en jefe, 
Clay Potts, ha estado trabajando enun proyecto de sistemas para la exi¬ 
tosa cadena de 15 florerías y mercados florales llamados Fields. En cada 
una de tres ciudades del Medio Oeste tienen cinco tiendas de distribu¬ 
ción Fields. .'* 

"Aunque ahora simplemente somosuna empresa en ciernes, en el fu¬ 
turo queremos extendernos a media docena de estados”, dice Seymour 
Fields, el dueño. "Quiero cosechar los beneficios de toda Ja felicidad que 
hemos sembrado hasta ahora. Pienso que esto lo podemos conseguir si¬ 
guiendo mi corazonada acerca del mejor momento para comprar las flo¬ 
res en cada mercado europeo al que acudimos, y reducir nuestras com¬ 
pras en otras fechas". 

"Durante los últimos tres años, he escrito muchos memorandos a; 
nuestros gerentes sobre este plan. Ellos también me han enviado algu-: 
nos planes buenos. Creo que estamos listos para arriesgarnos a implan¬ 
tar este plan a corto plazo en una parte del territorio”, continúa Seymour, 
describiendo un escenario promisorio para el futuro de Fields. 


"Estoy de acuerdo", interviene Rod. "Cuando termine de analizar 
estas cifras", dice, Indicando una gran pila de material que ha desen¬ 
terrado de las oficinas de campo de Fields, "podremos entregar una 
propuesta". ; 

Tres semanas después, Rod acude a Clay con la confianza por ¡os 
suelos. "No sé qué hacer con todo esto. No puedo dar con lo que está 
causando él crecimiento de la compañía, o cómo se maneja. La compa¬ 
ñía se ha estado extendiendo, pero he revisado todas las cifras y nada 
realmente parece tener sentido". 

Clay escucha con empatia y dice: "Me has dado una ¡dea. Lo que ne¬ 
cesitamos es un poco de polinización cruzada, una bocanada de aire 
fresco. Necesitamos Indagar más profundamente. ¿Examinaste todo, in¬ 
cluso sus estados de resultados?” . . 

Rod lo mira sorprendido y contesta: "No..., este..., ¿qué quieres decir?" 

¿Cómo puede explicar Potts diplomáticamente a Rod Golden que el 
examen de documentos tanto cualitativos como cuantitativos es funda¬ 
mental para ofrecer una evaluación precisa del potencial de Fields para 
convertirse en Una empresa más fructífera? En un párrafo, recomiende 
algunos documentos específicos que deberían leerse. Liste los pasos es¬ 
pecíficos que debe seguir Rod para evaluar los documentos cualitativos 
que obtenga de Fields. Explique en un párrafo de qué manera los docu¬ 
mentos cualitativos ayudan a presentar un panorama general del éxito 
de Fields. 


cualquier formulario basado en Web que requiera ser impreso por los usuarios. Por otra parte, 
deben identificarse las versiones electrónicas que se puedan distribuir por medio de la Web 
o el correo electrónico y almacenarse en una base de datos para una inspección posterior. 

Al crear un catálogo de formularios que le sirva para entender el flujo de información 
utilizada actualmente en la empresa: 

1. Recolecte ejemplos de todos los formularios en uso, ya sea que la empresa los haya 
aprobado oficialmente o no (formularios oficiales versus formularios improvisados}. 

2. Observe el tipo de formulario (si se imprimió en la organización, si se redactó a mano, 
si se hizo en computadora en la organización, si está en linea, si es para llenarse en la 
Web, si se envió a una imprenta, etcétera}. 

3. Documente el modelo de distribución deseado. 

4. Compare el modelo de distribución deseado con quien realmente recibe el formulario. 

Aunque este procedimiento requiere algo de tiempo, es útil. Otro método consiste en 
tomar muestras de los formularios de captura de datos que ya se hayan contestado. Al tomar 
muestras de las transacciones de comercio electrónico, recuerde revisar las bases de datos 
donde se almacena la información sobre el cliente. Como se ilustra en la figura 5.5, el ana¬ 
lista debe tomar en cuenta muchas preguntas específicas, entre ellas: 

1. ¿Los formularios se contestan en su totalidad? Si no es así, ¿qué elementos se han omi¬ 
tido? ¿Se omiten constantemente? ¿Por qué? 

2. ¿Hay formularios que nunca se usan? ¿Por qué? (Revise si el diseño y la aplicabilidad de 
cada formulario cumplen su función.} 

3. ¿Todas las copias de los formularios se distribuyen a las personas apropiadas o se archi¬ 
van adecuadamente? ¿Si no es así, por qué no? ¿Las personas que deben acceder a los 
formularios en línea, lo pueden hacer? 
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Preguntas relativas a los 
formularios oficiales e 
improvisados ya contestados. 




Cajas 


Pecha Nombre de tienda. 

Artículo p e d ¡do 

Lecíl e (1/2 galón) 

Entera 
2 % 

1 % 

Descremada 
Suero de la leche 
wioco/ate 

Yogurt 

Natural 
Vanilla 
Durazno 
Mora azul 
6a ya negra 
Fresa 
Helado 

Pintas de lujo 

.2 galón de lujo 
tmpaques - 

Individuales 


,ác!e °s fallantes 


Número de tienda 
Artículo pedido 

Leche (1/4 d e galón) 
Entera 

2 % 

1 % 

Descremada ^ 

Suero d^ la (eche 
Acólat 

Pina 

Manzana — 

Plátano — 

F uta s ! mixtas 
frambuesa — 

I .ilTlÓll -— 

de galón 


Ca]as 



El formulario, cfáfák 
ede abrumar al 

| información. 


(i P u . 

gicjiicttar 



El formulario 
podría carecer 
de un orden lógico. 


Pedido fjor (núm 


Causa de/ faltan 
Numero de conductor 

;ii$ Tienda._ 

Producto ¡altante 


. de empleado)^ 


de lujo 
Pintas premlum 
4 de galón 
Premium 

-Tota/ de 


da/as pedidas^ 



Fecha. 


Conductor_ 

Caía * ropuer/das 



¿En realidad 
es todo lo H U6 
„„ necesita? 


Aciales del gerente de la tienda 


Los formularios • 
"improvisados" 
ss conciben para 
simplificar el 
problema. 


4. Si hay un formulario impreso que se ofrezca como una alternativa a un formulario ba¬ 
sado en la Web, compare los porcentajes de contestación de ambos. 

5. ¿Se usan con frecuencia formularios "improvisados"? (Su uso podría indicar un proble¬ 
ma en los procedimientos normales o tal vez pugnas políticas en la organización.) 


ANÁLISIS DE LOS DOCUMENTOS CUALITATIVOS 


Los documentos cualitativos incluyen mensajes de correo electrónico, memorandos, carte¬ 
les en los tableros de anuncios y en las áreas de trabajo, páginas Web, manuales de proce¬ 
dimientos y manuales de políticas. Muchos de estos documentos son muy detallados y 
ponen de manifiesto las expectativas de sus autores en relación con el comportamiento que 
deben observar los demás. 
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Aunque muchos analistas de sistemas temen al análisis de documentos cualitativos, no 
hay razón para ello. Algunos lineamientos pueden ayudar a los analistas a seguir un enfoque 
sistemático en esta clase de análisis: 

1. Examine los documentos en busca de metáforas clave u orientadoras. 

2. Busque una mentalidad de internos contra externos o de "nosotros contra ellos". 

3. Liste los términos que caractericen lo bueno o lo malo y que aparezcan repetidamente 
en los documentos. 

4. Busque mensajes y gráficos significativos colocados en áreas comunes o en páginas 
Web. 

5. Identifique el sentido del humor, si lo hay. 

El examen de los documentos en busca de metáforas clave u orientadoras se hace 
porque el lenguaje moldea el comportamiento; por lo tanto, es muy importante cuidar las 
metáforas que utilicemos. Por ejemplo, una organización que se refiere a sus empleados 
como "parte de una gran máquina" o "dientes de un engranaje" podría estar adoptando 
una vista mecanicista de la organización. Observe que la metáfora orientadora del memo¬ 
rando de la figura 5.6 es "Somos una gran familia feliz". El analista puede usar esta informa¬ 
ción para predecir qué tipos de metáforas serán persuasivas en la organización. Obviamen¬ 
te, si un departamento está en conflicto con otro, sería imposible obtener cooperación 
alguna para un proyecto de sistemas hasta que el conflicto se resuelva de una manera sa¬ 
tisfactoria. Valorar el uso del humor proporciona un barómetro rápido y exacto de mu¬ 
chas variables de la organización, incluyendo a qué grupo social pertenece una persona y 
qué tipo de moral tiene. 

Memorandos Junto con los cinco lineamientos anteriores, el analista también debe consi¬ 
derar quién envía los memorandos y quién los recibe. Generalmente, la mayoría de la infor¬ 
mación en las organizaciones fluye hacia abajo y horizontalmente en lugar de hacia arriba, y 
sistemas de correo electrónico envían mensajes a muchos grupos de trabajo e individuos. 
Los memorandos ponen de manifiesto un diálogo vigoroso y continuo en la organización. El 
análisis del contenido de los memorandos le proporcionará una idea clara de los valores, ac¬ 
titudes y creencias de los miembros de la organización. 
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IT análisis de memorandos 
proporciona un panorama de las 
metáforas que guían la manera 
de pensar de la organización. 
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Los carteles manifiestan la 
cultura oficial de la organización. 



Carteles o pancartas en los tableros de anuncios o en las áreas de trabajo Aunque los car¬ 
teles podrían parecer circunstanciales en relación con lo que ocurre en la organización, sir¬ 
ven como reforzadores sutiles de valores para aquellos que los leen, como se describe en la 
figura 5.7. Los carteles como "La calidad es para siempre" o "Primero está la seguridad" pro¬ 
porcionan al analista una percepción de la cultura oficial de la organización. 

Sitios Web corporativos El analista también debe poner atención en los sitios Web que se 
usan en el comercio electrónico negocio a cliente (B2C), al igual que aquellos que se usan 
para las transacciones negocio a negocio (B2B}. Examine los contenidos en busca de metá¬ 
foras, humor, uso de características de diseño (como el color, gráficos, animación e hiper- 
vínculos) y el significado y claridad de cualquier mensaje. Visualice el sitio Web desde tres 
dimensiones: técnica, estética y administrativa. ¿Hay inconsistencias entre las metas estable¬ 
cidas por la organización y lo que se le presenta al usuario del sitio? ¿Cuánto se le permite 
a cada usuario adaptar a su gusto el sitio Web? ¿Cuánto se puede personalizar el sitio Web? 
Si usted no va a diseñar los sitios de comercio electrónico de la organización, ¿cómo afec¬ 
tará lo que ve en el sitio Web a los sistemas que está investigando? No olvide tomar nota 
del nivel de interactividad del sitio o sitios Web, de la accesibilidad de los mensajes y del 
nivel de seguridad. 

Manuales Otros documentos cualitativos que el analista debe examinar son los manuales 
de la organización, incluyendo los manuales de procedimientos de operación de las compu¬ 
tadoras y los manuales en línea. Los manuales se deben analizar con los cinco lincamientos 
que se explicaron anteriormente. Recuerde que los manuales indican el "ideal", la forma 
en que se espera que las máquinas y las personas se comporten. Es importante recordar que 
por lo regular los manuales impresos no están actualizados y a veces se dejan olvidados en 
un estante, sin usar. 

Manuales de políticas El último tipo de documento cualitativo que consideraremos es 
el manual de políticas. Aunque por lo general estos documentos abarcan grandes áreas del 
comportamiento de los empleados y la organización, usted se puede ocupar en primer lugar 
de los que tratan sobre las políticas sobre los servicios, uso, acceso, seguridad y cargas de las 
computadoras. El examen de las políticas permite al analista de sistemas comprender los va¬ 
lores, actitudes y creencias que guían a la corporación. 
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EXPERIENCIA CON HYPERCASE® 


"Nos alegramos de que usted considere a MRE como un lugar interesante de consulta. Se¬ 
gún los rumores, usted ha estado ocupado explorando las oficinas. Lo sé, hay tanto por ver. 
A nosotros nos cuesta trabajo mantenernos al tanto de todo. Algo de lo que nos hemos ase¬ 
gurado siempre es que procuramos usar los métodos en los que creemos. ¿Ha visto alguno 
de nuestros informes? ¿Qué tal los datos recopilados en los cuestionarios de Snowdcn? Al 
parecer, él prefiere los cuestionarios por encima de cualquier otro método. Algunas perso¬ 
nas los odian, pero creo que usted puede aprender mucho de los resultados. Algunas per¬ 
sonas han demostrado buena disposición para cooperar en estos proyectos. ¿Ya conoció a 
Kathy Blandford?". 





PREGUNTAS DEL HYPERCASE 

1. Aproveche las pistas del caso para evaluar la experiencia en cómputo de la Unidad de 
Capacitación y el sentir de su personal sobre un sistema cómputarizado de seguimien¬ 
to de proyectos. ¿Cuál cree que sea el consenso en la Unidad de Capacitación hacia un 
sistema de seguimiento compútarizado?. 

2. ¿Qué informes y estados genera la Unidad de Capacitación durante el desarrollo de 
proyectos? Liste cada uno con una breve descripción. 

3. ¿De acuerdo con los resultados de la entrevista, cuáles son los problemas con el sistema 
actual de seguimiento de proyectos en la Unidad de Capacitación?; 

4. Describa el "conflicto de administración de proyectos" en MRE. ¿Quién está involucra¬ 
do? ¿Por qué hay un conflicto? 

5. ¿Cómo da seguimiento la Unidad de Sistemas de Administración al progreso de los 
proyectos? Describa brevemente el método o sistema. 


OBSERVACION DEL COMPORTAMIENTO DEL TOMADOR DE DECISIONES 

La observación del tomador de decisiones y su entorno físico son métodos no intrusivos im¬ 
portantes para el analista de sistemas. Al observar las actividades del tomador de decisiones, 
el analista busca darse una idea de lo que realmente se hace, no sólo de lo que se documenta 
o explica. Además, al observar al tomador de decisiones, el analista trata de ver personal¬ 
mente las relaciones que existen entre el tomador de decisiones y los demás miembros de la 
organización. 

OBSERVACIÓN DE LAS ACTIVIDADES DE TOMA DE DECISIONES DE UN GERENTE TÍPICO 

Los días laborales de los gerentes se han descrito como una serie de interrupciones entre¬ 
mezcladas con breves ráfagas de trabajo. En otras palabras, identificar con exactitud lo que 
un gerente "hace" es un asunto delicado incluso en el mejor de los casos. El analista de sis¬ 
temas se vale de entrevistas y cuestionarios interactivos para entender adecuadamente la 
manera en que los gerentes describen su trabajo. Sin embargo, la observación permite al 
analista ver personalmente la manera en que un gerente recopila, procesa, comparte y usa la 
información para realizar su trabajo. 

Aunque es posible usar cuadros y flechas para describir y documentar la manera en que 
los gerentes toman decisiones, ante todo estamos describiendo a personas y sus actividades. 
Por lo tanto, sugerimos que los analistas de sistemas usen un método más humanístico para 
describir lo que hacen los gerentes. Este método se conoce como el guión del analista. En 
esta técnica el "actor" es el tomador de decisiones quien es observado "actuando" o tomando 
decisiones. Como se muestra en la figura 5.8, al crear el guión el actor se pone en la colum¬ 
na izquierda y todas sus acciones en la columna derecha. Todas las actividades se registran 
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Una página de muestra del 
guión del analista que describe 
la toma de decisiones. 


Análisis Empresa: Solid Steel Shelving ArgumentO.'Aseguramiento 
— del guión Analista: L. Bracket de la calidad 

t — . _ ' —Fecha: 9/3/2003 

Toma.üj’rje - -- --- 

gÜITIT — ¡ nformapllS „ 


frente de -- a MAJa 

aseguramiento *1 supervisor j. 

de la calidad el lnfo ™e de D m*,Í, S 1S ° de la tienda 

ai.tion del día 


§SPSá v %l'iíidá e pi s0 55Rpy£firS!¿§S¿ amente el informe de producción 


Gerente de 
aseguramiento 
de la calidad 


"Sí 

Dispute con el gerente de aseguramiento de ia ' ¡im 
calidad (QA) los problemas recurrentes en las fea 
corridas de producción 


Lee el informe de producción 


actual con otros informes ' • t ||í 


Introduce datos de la producción diaria en i® 
el modelo de QA de la computadora .',s;l 


pantalla los resultados del 


Llama a los proveedores de acero para discutir ; \|¡ií 
las desviaciones de Aes’hsfáncSires de calidad j 
A^-^ó> e á v Í#QÍ I °ne5*de "los estándare ,0|- 

Supervisor de piso Asiste a la reunión de las nuevas H 

especificaciones de calidad con . el gerente. jtlií 
■ de aseguramiento de la calidad y el p|¡ 

.erente de vicepresidente de producción. " fe;-; 


■ Gerente de 
aseguramiento 
de la calidad 


Hace borradores de cartas para informar a los 
proveedores las nuevas especificaciones de pió 
calidad establecidas en la reunión ; 


Vice pr e s idente de 
Producción 


geH-io^etegíVÍeB 63 al vicepresidente por 


Lee los borradores 


Gerente de 
aseguramiento 
de la calidad 


Regresa las correcciones y comentarios por 
correo electrónico 


¿e?riíJfdS 


rreo electrónico las cartas 


gvamente las cartas para reflejar 


|||"|| 


con verbos conjugados, de manera que un tomador de decisiones se podría describir como 
"hablando", "tomando muestras", "correspondiendo" y "decidiendo". 

El guión es un método organizado y sistemático que exige al analista entender y estruc¬ 
turar la acción asumida por cada uno de los tomadores de decisiones que haya observado. 
Con el tiempo, este método ayudará al analista de sistemas a determinar qué información 
necesitan las personas observadas para tomar las decisiones más importantes o frecuentes. 
Por ejemplo, en el caso del gerente de aseguramiento de la calidad del guión, es claro que 
aunque este tomador de decisiones forma parte de la gerencia de nivel medio, necesita una 
gran cantidad de información externa para realizar las actividades propias de este trabajo 
específico. 
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OBS ÉRWÍCIÚ'Í D E L'E NTORIOFÍSÍCO 

La observación de las actividades de los tomadores de decisiones es sólo una forma de 
evaluar sus requerimientos de información. La observación del entorno físico en el cual se 
desempeñan los tomadores de decisiones también pone de manifiesto muchos de sus re¬ 
querimientos de información. Con mucha frecuencia, dicha observación implica examinar 
sistemáticamente las oficinas de los tomadores de decisiones, ya que éstas constituyen su 
principal lugar de trabajo. Los tomadores de decisiones influyen en, y a su vez reciben in¬ 
fluencia de, sus entornos físicos. 

OBSERVACIÓN ESTRUCTURADA DEL ENTORNO (STROBE) 

Los críticos de cine a veces recurren a una forma de crítica estructurada conocida como 
análisis de escenario para evaluar sistemáticamente lo que hay en una sola toma de la pe¬ 
lícula. Revisan la edición, el ángulo de la cámara, la decoración del set y a los actores y su 
vestuario para descubrir si le están dando forma al contenido de la película como el direc¬ 
tor lo desea. A veces el escenario de la película no corresponde con lo que se dice en el diá¬ 
logo. El analista de sistemas puede asumir un papel similar al del crítico de cine para el aná¬ 
lisis de los requerimientos de información. A menudo es posible observar las circunstancias 
del entorno que confirmarán o negarán el discurso (o diálogo] de la organización que se re¬ 
fleja en las entrevistas o cuestionarios. 

El método para la Observación Estructurada del Entorno (STRuctured OBservation of 
the Environment) se conoce como STROBE. La aplicación exitosa del STROBE requiere 
que el analista observe explícitamente siete elementos concretos que por lo general se en¬ 
cuentran en las oficinas. En la figura 5.9 se describen dichos elementos y algunas preguntas 
importantes que podrían surgir. Estos elementos pueden revelar mucho sobre la forma en 
que el tomador de decisiones recopila, procesa, almacena y comparte la información, así co¬ 
mo también sobre su credibilidad en el lugar de trabajo. 


Elemento observable 


Preguntas que el analista podría Investigar 


Ubicación de la oficina 


Colocación del escritorio 


¿Quién tiene la oficina de la esquina? ¿Los tomadores 
de decisiones importantes están dispersos en los 
diferentes pisos? : 

¿La colocación del escritorio favorece la comunicación? 
¿La colocación demuestra la autoridad? 


Equipo fijo 


¿El' tomador dé decisiones prefiere;recopilar y 
almacenar la información:personalmente? ¿El area. 
de almacenamiento es grande o pequeña? 


Accesorios 


¿Hay evidencia de que el tomador de decisiones 
utiliza la PC? ¿Hay computadoras portátiles o de 
bolsillo en la oficina? 


Fuentes externas de información 


Iluminación y color de la oficina 


Vestimenta de los tomadores 
de decisiones .' A ' ’ 


: ¿El; tomador de decisiones.obtiene mucha .? 

, información de fuentes externas tales como revistas 
especializadas o Web?' '• : \ 

¿La iluminación es propicia para un trabajo detallado 
o es más apropiada para la comunicación casual? 
¿Los colores son cálidos y llamativos? 

¿El tomador de decisiones muestra autoridad; 
cuándo so oone trajes conservadores? ¿EÍTjáft; 
reglamentario que lós empleados porten uniformes? 



Siete elementos concretos 
que se deben observar en 
el STROBE y ejemplos de 
preguntas que un analista podrfa 
hacen ..; / ?: /": . 
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Ubicación de !a oficina Uno de los primeros elementos que el analista de sistemas debe 
observar es la ubicación de la oficina de un tomador de decisiones específico con respecto 
a otras oficinas. Las oficinas accesibles tienden a aumentar la frecuencia de la interacción y 
los mensajes informales, mientras que las oficinas inaccesibles tienden a disminuir la fre¬ 
cuencia de la interacción y a aumentar los mensajes orientados a las tareas. El resultado de 
que las oficinas se distribuyan por todo el edificio es que con frecuencia un informe o me¬ 
morando se queda detenido en una de las oficinas, mientras que en las oficinas agrupadas se 
favorece el compartir la información. También es probable que las personas cuyas oficinas 
están separadas de las de los demás pudieran ver a la organización de forma diferente y sus 
objetivos podrían alejarse de los de otros miembros de la organización. 

Colocación del escritorio La colocación de un escritorio en la oficina puede ofrecer pistas 
sobre la manera en que el tomador de decisiones ejerce su autoridad. Los ejecutivos que 
confinan a un visitante a un espacio reducido y con la espalda a la pared mientras ellos tie¬ 
nen exceso de espacio, adoptan la posición de autoridad más fuerte posible. Un ejecutivo 
que coloca su escritorio frente a la pared con una silla al lado para un visitante estimula la 
participación y los intercambios equitativos. El analista de sistemas debe observar la distribu¬ 
ción de los muebles de la oficina y en particular la colocación del escritorio. La figura 5.10 
muestra un ejemplo de colocación del escritorio así como también de muchos de los demás 
elementos del STROBE, como los accesorios, el equipo fijo de oficina, la iluminación, el co¬ 
lor y las fuentes de información externas. 

Equipo fijo de oficina Archiveros, libreros y otro equipo grande para almacenar artículos 
se incluyen en la categoría de equipo fijo de oficina. Si no hay tal equipo, es probable que el 
tomador de decisiones almacene muy pocos artículos de información por sí mismo. Si hay 
una abundancia de tal equipo, se asume que el tomador de decisiones almacena y valora 
mucha información. 

Accesorios El término accesorios se refiere a todo el equipo pequeño usado para procesar 
información, incluso las computadoras de bolsillo, calculadoras, PCs, plumas, lápices y re¬ 
glas. La presencia de computadoras de bolsillo, calculadoras y PCs sugiere que un tomador 
de decisiones que posee dicho equipo es más probable que lo use personalmente que uno 
que debe salir de la oficina para usarlo. 



Observe la oficina de un tomador 
de decisiones para darse una 
idea de la manera en que 
almacena, procesa y distribuye 
la información. 



Archivar) 


CD-RWs 


Iluminación 

fluorescente 


KetAetas especializadas 

en el estante 


PC 

sobre el 
escritorio 
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Fuentes externas de información Un analista de sistemas necesita saber qué tipo de infor¬ 
mación usa el tomador de decisiones. La observación del tipo de publicaciones almacenadas 
en la oficina puede revelar si el tomador de decisiones recurre a información externa (en re¬ 
vistas de comercio, recortes de periódico sobre otras compañías de la industria, etc.) o se 
basa más en la información interna (informes de la compañía, correspondencia de la ofici¬ 
na, manuales de políticas). El analista también debe observar si el tomador de decisiones 
prefiere conseguir información externa en la Web. 

Humillación y color de la oficina La iluminación y el color juegan un papel importante en 
la manera en que un tomador de decisiones recopila información. Una oficina con ilumina¬ 
ción cálida y radiante indica una tendencia hacia la comunicación más personal. Un ejecu¬ 
tivo en una oficina iluminada cálidamente recopilará más información de manera informal, 
mientras que otro miembro de la organización que trabaja en una oficina iluminada con 
gran colorido podría recopilar información a través de memorandos más formales e infor¬ 
mes oficiales. 

Vestimenta de los tomadores de decisiones Se ha escrito mucho sobre la vestimenta de los 
ejecutivos y demás personal con algún grado de autoridad. El analista de sistemas puede 
darse una idea de la credibilidad de los gerentes de la organización al observar la vestimen¬ 
ta que usan en el trabajo. El traje de dos piezas para un hombre o el traje con falda para una 
mujer representan la máxima autoridad, de acuerdo con algunos investigadores que han es¬ 
tudiado las percepciones sobre la apariencia de los ejecutivos. El hecho de que los líderes 
vistan de manera casual tiende a abrir las puertas para una toma de decisiones más partici- 
pativa, pero a menudo propicia la pérdida de credibilidad en la organización si la cultura 
predominante valora la ropa tradicional y conservadora. 

Mediante el STROBE, el analista de sistemas puede darse una mejor idea de la manera 
en que los gerentes recopilan, procesan, almacenan y usan la información. En la figura 5.11 
se muestra un resumen de las características mostradas por los tomadores de decisiones y sus 
elementos observables correspondientes. 


APLICACIÓN DEL STROBE 

Una forma de implementar el STROBE es mediante el uso de una lista de verificación anec¬ 
dótica con símbolos taquigráficos. Este enfoque del STROBE fue útil para determinar los 
requerimientos de información de cuatro tomadores de decisiones importantes en una tien¬ 
da de ropa. 


Elementos correspondientes 

Características del tomador de decisiones en el entorno físico 

■ Recopila información de manera informal • Iluminación cálida y radiante :: ;■; 

Busca información fuera de la organización Revistas especializadas presentes en la oficina 
Procesa los datos personalmente ■ . PCs y, computadoras portátiles presentes en la oficina 

Almacena la información personalmente Equipo/archivos presentes en la oficina 

Ejerce autoridad en la toma de decisiones Ubica el escritorio para reflejar su autoridad ■■ , 

Muestra credibilidad en la toma de decisiones Viste trajes que reflejan su autoridad 
(;■«>.• »,-ert*í información con otros'.' , La oficina es. fácilmente accesible 



Resumen de características de 
un tomador de decisiones'que ' 
corresponden con. elementos . 
observables en el entorno físico. 
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NO DEPENDA DE SU AUTOIMAGEN 


NO TODO SE REFLEJA EN UN ESPEJO 


"Yo no necesito ninguna autoridad aquí”, objeta el doctor Drew Char¬ 
les, director médico del banco de sangre regional donde su grupo de sis¬ 
temas recién ha empezado un proyecto. "Bastantes problemas tengo para 
mantener informados a los médicos regionales para que sigan buenas 
prácticas en la recolección de sangre", dice, al tiempo que se protege los 
ojos de la resplandeciente luz del sol que se cuela en su oficina. Apaga el 
monitor de su PC y le presta atención a usted y a la entrevista. 

El doctor Charles viste un conservador traje de lana oscuro y una 
corbata de seda con rayas rojas. Continúa: "De hecho, yo no tomo las 
decisiones. Mi función es meramente de apoyo". El doctor saca el organi¬ 
grama mostrado en la figura 5.C1 para ¡lustrar su punto. "Está tan cla¬ 
ro como una fractura. El administrador principal es el experto en todas 
las cuestiones administrativas. Yo sólo soy el consultor médico." 

La oficina del doctor Charles no sólo está repleta de revistas médicas 
como Transfusión sino también con la revista BYTE]/e I Business Week. 
Cada uno está abierto en una página diferente, como si el doctor estu¬ 
viera a punto de devorar cada nuevo bocado de información. Sin embargo, 
el exceso de periódicos no se guarda meticulosamente en los estantes de 
metal como cabría esperar. En contraste con el nuevo y reluciente equipo 
que se usa en las habitaciones de los donantes, los periódicos se amon¬ 
tonan en una vieja cama para donar sangre que hace bastante tiempo 
dejó de utilizarse para ese fin. 

A continuación, usted decide entrevistar al administrador principal, 
Craig Bunker, a quien se refirió el doctor Charles. Quince minutos después 
del inicio programado para la entrevista, la secretaria de Bunker, Dawn 
Upshaw, finalmente le permite a usted entraren la oficina. Bunker, quien 
recién ha terminado una llamada telefónica, viste un saco sport azul 
claro, pantalones a cuadros, camisa azul y una corbata. "¿Cómo le va? 
Sólo estaba checando qué tan animadas están las cosas", dice Bunker a 
manera de introducción. Se muestra muy amigable y extrovertido. 


Al pasear la mirada por la habitación, usted se percata de que no hay 
archiveros, ni una PC como la del doctor Charles. Hay muchas fotogra¬ 
fías de la familia de Craig Bunker, pero el único artículo parecido a un li¬ 
bro o una revista es el boletín del banco de sangre, Bloodline. Cuando la 
entrevista empieza en serio, Bunker empieza a narrarle alegremente 
anécdotas del Banco de Sangre de Pennsylvania donde él desempeñó el 
puesto de administrador auxiliar hace seis años. 

Finalmente, usted desciende los escalones del húmedo sótano del 
Heat Lambed Mansión. Los vehículos que recolectan sangre recién han 
vuelto, y procesan la sangre que se ha enviado a los hospitales del área. 
Usted decide hablar con Sang Kim, conductor de uno de los vehículos re¬ 
colectores de sangre; con Jenny McLaughlin, gerente de distribución, y 
con Robeda Martin, laboratorista que trabaja en el turno nocturno. 

Robería empieza: "No sé qué haríamos sin el doctor". En el mismo te¬ 
nor, Sang hace notar: "Sí, él nos ayudó a planear un mejor horario de ma¬ 
nejo la semana pasada". 

Jenny agrega: "La ayuda del doctor Charles es invaluable para fijar 
los niveles de inventario de cada hospital, y si no fuera por él, aún no 
tendríamos el procesador de texto, por no mencionar nuestra nueva 
computadora". 

Como uno de los miembros del equipo de análisis de sistemas asig¬ 
nado al proyecto del banco de sangre, desarrolle una lista de verificación 
anecdótica con el STROBE que le sirva para interpretar sistemáticamen¬ 
te las observaciones que hizo en las oficinas del doctor Charles y Craig 
Bunker. Tome en cuenta las discrepancias entre las vestimentas de los 
tomadores de decisiones, lo que manifiestan y lo que dicen los demás; 
entre la ubicación de las oficinas y lo que se indica; y entre el equipo de 
oficina y las políticas establecidas. Además, en un párrafo, sugiera posi¬ 
bles entrevistas de seguimiento y observaciones que sirvan para arreglar 
cualquier cuestión pendiente. 


Administrador 

principal 


Director 

médico 


Recolección I Distribución I ¡ Sistemas 

desangre desangre j Contabll,dad de cómputo 


Asistentes 


Laboratorio 1 Enfermería i Investigación! 
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Organigrama del banco de sangre regional. 
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Una lista anecdótica fcDh- 
símbolos que se IjkJpteft para 
aplicar el STROi.?f :' : ;;f 


Como se puede ver en la figura 5.12, los analistas de sistemas utilizaron cinco símbolos 
taquigráficos para evaluar cómo se comparaba la observación de los elementos del STROBE 
con el discurso organizacional derivado de las entrevistas. Los cinco símbolos son: 

1. Una marca de verificación significa que el discurso está confirmado. 

2. Una "X" significa que el discurso se contradice. 

3. Un símbolo de óvalo, o forma de ojo, es una señal para que el analista de sistemas ahon¬ 
de en el asunto. 

4. Un cuadrado significa que la observación de los elementos del STROBE modifica el 
discurso. 

5. Un círculo significa que el discurso se complementa por lo que se observa. 
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Cuando el STROBE se lleva a cabo de esta manera, el primer paso es anotar los temas 
importantes de la organización que se originan de las entrevistas. Posteriormente se obser¬ 
van los elementos del STROBE y se registran. Una vez que se comparan el discurso y las 
observaciones, se usa uno de los cinco símbolos apropiados para representar la relación. De 
esta manera, el analista crea una tabla que primero documenta y luego ayuda en el análisis 
de las observaciones. 



RESUiEN 


Este capítulo ha tratado los métodos no intrusivos para la recopilación de información, in¬ 
cluyendo el muestreo; investigación de datos cuantitativos y cualitativos en los formularios 
actuales y en los archivados, y la observación de las actividades del tomador de decisiones a 
través del uso del guión del analista, como también de la observación del entorno físico del 
tomador de decisiones mediante el STROBE. 

El proceso de seleccionar sistemáticamente elementos representativos de una población 
se llama muestreo. El propósito del muestreo es seleccionar y estudiar documentos como 
facturas, informes de ventas y memorandos, o quizás seleccionar y entrevistar, aplicar cues¬ 
tionarios y observar a los miembros de la organización. El muestreo puede reducir costos, 
acelerar la recopilación de datos, hacer potencialmente más eficaz el estudio y quizá redu¬ 
cir la desviación en el estudio. 

Un analista de sistemas debe seguir cuatro pasos para diseñar una buena muestra. Pri¬ 
mero, necesita delimitar la población en sí. Segundo, debe decidir el tipo de muestra. Ter¬ 
cero, tiene que calcular el tamaño de la muestra. Por último, debe planear los datos que se 
tienen que recolectar o describir. 

Los tipos de muestras útiles para el analista de sistemas son las muestras de convenien¬ 
cia, las muestras intencionales, las muestras aleatorias simples y las muestras aleatorias com¬ 
plejas. El último tipo incluye las subcategorías de muestreo sistemático y muestreo estrati¬ 
ficado. Hay varios lincamientos a seguir al determinar el tamaño de la muestra. El analista 
de sistemas puede tomar una decisión subjetiva respecto a las estimaciones del intervalo 
aceptable, después elige un nivel de confianza y a continuación puede calcular el tamaño 
necesario de la muestra. 

Los analistas de sistemas necesitan investigar los datos y formularios actuales y los ar¬ 
chivados, incluyendo informes, documentos, estados financieros, contenido de los sitios Web 
corporativos, formularios en la Web diseñados para imprimirse y aquellos que se envían 
electrónicamente, manuales de procedimientos, y contenido del correo electrónico y me¬ 
morandos. Los datos y formularios actuales y los archivados revelan en dónde ha estado la 
organización y hacia dónde creen los miembros que se dirige. Es necesario analizar los do¬ 
cumentos cuantitativos y cualitativos. Dado que los documentos son mensajes persuasivos, 
se debe reconocer que cambiándolos bien se podría cambiar la organización. 

Los analistas usan la observación como una técnica de recopilación de información. 
Mediante la observación se dan una idea de lo que realmente se hace. Una forma de descri¬ 
bir cómo se comportan los tomadores de decisiones es utilizar un guión de analista para 
documentar las actividades de cada uno de los actores principales. 

Además de observar la conducta de un tomador de decisiones, el analista de sistemas 
debe observar el entorno del tomador de decisiones. Un método es la Observación Es¬ 
tructura del Entorno, o STROBE. Un analista de sistemas usa el STROBE del mismo modo 
que un critico de cine usa un método llamado análisis de escenario para analizar una toma 
de la película. 

Se pueden observar e interpretar algunos elementos concretos en el entorno del toma¬ 
dor de decisiones. Estos elementos incluyen (1) la ubicación de la oficina; (2} la colocación 
del escritorio del tomador de decisiones; (3) el equipo fijo de oficina; [4] los accesorios co- 
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"Estamos orgullosos de nuestro edificio aquí en Tennessee. De hecho, contratamos al despa¬ 
cho de arquitectos I. M. Paid para conservar el mismo tema, mimetizándonos con el paisaje 
local mientras al tiempo nos mantenemos accesibles para nuestros clientes, en todas las di¬ 
visiones. Recibimos a muchas personas que vienen tan sólo para admirar el edificio una vez 
que se dan cuenta dónde está exactamente. |I)e hecho, para los estándares de Tennessee te¬ 
nemos tantos visitantes como si se tratara de las pirámides! Bien, usted podrá apreciarlo por 
sí mismo conforme avance. El Atrio Oriental es mi lugar favorito: pletórico de luz, con una 
gran cantidad de persianas para filtrarla. Siempre me ha fascinado que el edificio y su mobi¬ 
liario podrían contar una historia bastante diferente de la que contarían sus ocupantes." 

"A veces los empleados se quejan de que las oficinas tienen la misma apariencia. No 
obstante, los salones públicos son espectaculares. Incluso la cafetería es atrayente. La mayo¬ 
ría de las personas no puede opinar lo mismo de las cafeterías de sus trabajos. De cualquier 
manera, usted notará que todos personalizamos nuestras oficinas. Así. aun cuando todas las 
oficinas tuvieran la misma apariencia, las personalidades de sus ocupantes: parecen apode¬ 
rarse de ellas apenas comienzan a ocuparlas. ¿Qué ha visto usted? ¿Hasta aquí hay algo que 
lo haya sorprendido?" 

PREGUNTAS DE HYPERCASE 

1. Use el STROBE para comparar y contrastar las i oficinas de Snowden Evans y de Ket- 
cham. ¿Qué conclusión puede obtener de sus observaciones sobre la manera en que ca¬ 
da persona utilizada tecnología de información? ¿Qué tan compatibles parecen Evans y 
Ketcham por lo que se refiere a los sistemas que usan? ¿Qué otras pistas puede descu¬ 
brir sobre la manera en que almacenan, usan y comparten la información tomando co¬ 
mo base las observaciones de sus oficinas? : 




Hay pistas ocultas en el HyperCase, Para descubrirlas utilice el STROBE. 
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2. Examine cuidadosamente la oficina de Kathy Blandford. Use el STROBE para 
confirmar, contradecir o negar lo que haya descubierto durante su entrevista con 
ella. Mencione algo que haya averiguado sobre la señorita Blandford al observar 
su oficina que no haya descubierto en la entrevista. 

3. Analice con cuidado la recepción de MRE mediante el STROBE. ¿Qué inferen¬ 
cias puede hacer sobre la organización? Redáctelas. ¿Qué preguntas de entrevista 
le gustaría plantear, con base en sus observaciones de la recepción? Haga una lista 
de las personas que le gustaría entrevistar y las preguntas que desearía plantear a 
cada una de ellas. 

4. Describa en un párrafo el proceso que tendría que realizar para aplicar el STRO¬ 
BE en el contexto de una oficina de MRE. Mencione todos los elementos de las 
oficinas de MRE que parezcan importantes para comprender el comportamiento 
relacionado con la toma de decisiones de los usuarios. 



mo las computadoras de bolsillo y las PCs; (5) las fuentes externas de información como las 
revistas especializadas y el uso de la Web; (6) la iluminación y el color de la oficina, y (7) la 
vestimenta de los tomadores de decisiones. El STROBE se puede usar para entender mejor 
la manera en que los tomadores de decisiones recopilan, procesan, almacenan y comparten 
realmente la información. 


PALABRAS Y FRASES CLAVE 


accesorios (computadoras de bolsillo 
y PCs) 

colocación del escritorio 
comercio electrónico negocio a cliente 
(B2C) 

comercio electrónico negocio a negocio 
(B2B) 

equipo fijo de oficina 
fuentes de información externas 
guión del analista 
iluminación y color de la oficina 
muestra aleatoria compleja 
muestra aleatoria simple 
muestra de conveniencia 


muestra intencional 
muestreo 

muestreo estratificado 
muestreo por conglomerados 
muestreo sistemático 
nivel de confianza 
observación sistemática 
población de muestra 
sitios Web corporativos 
STROBE 

ubicación de la oficina 
vestimenta de los tomadores de 
decisiones 


PREGUNTAS DE REPASO 

1. Defina el significado de muestreo. 

2. Mencione cuatro razones por las cuales el analista de sistemas necesitaría tomar mues¬ 
tras de datos o seleccionar personas representativas para entrevistar. 

3. ¿Cuáles son los cuatro pasos que se deben seguir para diseñar una buena muestra? 

4. Mencione los tres tipos de muestra aleatoria compleja. 

5. Defina el significado de la estratificación de muestras. 

6. ¿Qué efecto se produce en el tamaño de la muestra al usar un mayor nivel de confian¬ 
za al tomar muestras del atributo? 
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7. ¿Cuál es la principal variable que determina a cuántas personas debe entrevistar a pro¬ 
fundidad el analista de sistemas? 

8. ¿Qué información sobre el tomador de decisiones busca descubrir el analista a través de 
la observación? 

9. Mencione cinco pasos para ayudar al analista a observar las actividades típicas del to¬ 
mador de decisiones. 

10. ¿Quién es el actor en la técnica conocida como guión del analista? 

11. ¿En el guión del analista, qué información de los gerentes se registra en la columna 
derecha? 

12. Tomando en cuenta que la idea del STROBE proviene del mundo del cine, ¿a cuál pa¬ 
pel se asemeja el papel del analista de sistemas? 

13. Mencione los siete elementos concretos del entorno físico del tomador de decisiones 
que el analista de sistemas puede observar mediante el STROBE. 


PROBLEMAS 


1. Dee Fektiv está preocupada porque demasiados formularios se están contestando in¬ 
correctamente. Dee cree que alrededor de 10 por ciento de todos los formularios tiene 
un error. 

a. ¿Qué tamaño de muestra debe usar Dee para tener 99 por ciento de certeza de 
que estará dentro de 0.02 por ciento del dato real? 

b. Suponga que Dee aceptará un nivel de confianza de 95 por ciento que estará den¬ 
tro de 0.02. ¿Cuál será ahora el tamaño de la muestra de formularios? 

2. "Veo que usted tiene bastantes papeles allí. ¿Qué tanto tiene?", le pregunta Betty Kant, 
jefa del grupo de trabajo de MIS que funge de enlace entre su grupo de sistemas y la 
Sawder's Furniture Company. Usted está revolviendo un gran legajo de documentos 
mientras se prepara para salir del edificio." 

"Bueno, tengo algunos estados financieros, informes de producción de los últimos 
seis meses y algunos informes de desempeño que Sharon me dio sobre el cumpli¬ 
miento de las metas y el desempeño laboral durante los últimos seis meses", contesta 
usted al tiempo que algunos de los documentos caen al suelo. "¿A qué se debe la pre¬ 
gunta?" 

Betty le quita los papeles y los pone en el escritorio más cercano. En seguida le res¬ 
ponde: "Porque no necesita toda esta basura. Usted está aquí con un propósito, y ése es 
hablar con nosotros, los usuarios. Le aseguro que nada de lo que pueda leer de esto re¬ 
presentará una gran diferencia". 

a. La única forma de convencer a Betty de la importancia de cada documento es de¬ 
cirle lo que usted está buscando en cada uno. En un párrafo explique lo que cada 
tipo de documento le ofrece al analista de sistemas para entender el negocio. 

b. Mientras usted está hablando con Betty, se da cuenta de que en realidad también 
necesita otros documentos cuantitativos. Mencione alguno que le falte. 

3. Ha tomado muestras de los mensajes de correo electrónico que se han enviado a varios 
gerentes de nivel medio de la Sawder's Furniture Company, que distribuye en todo el 
país sus muebles de madera aglomerada. Aquí hay uno que repite un mensaje encon¬ 
trado en varios memorandos más: 

A: Sid, Ernie, Cari 
De: Imogene 

Re: proveedores de computadoras/impresoras 
Fecha: 10 de noviembre de 2003 


Me ha llamado la atención que he estado librando una guerra contra los pedidos de 
consumibles para computadoras e impresoras (discos, tóner, papel, etc.) que están fue¬ 
ra de toda proporción de lo que se ha negociado en el presupuesto actual. Como aquí 
todos somos buenos soldados, tengo la esperanza de que ustedes entenderán todo lo 
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que nuestro sargento de abastecimiento diga que es normal. Por favor, "no hagan ningu¬ 
na solicitud a media noche" para compensar los faltantes. Gracias por su comprensión; 
esto nos facilita la batalla a todos. 

a. ¿Qué metáfora(s) se está(n) usando? Mencione la metáfora predominante y otras 
frases que se empleen en el mismo sentido. 

b. ¿Si encontrara evidencia repetida de esta idea en otros mensajes de correo electró¬ 
nico, qué interpretación tendría? Dé su explicación en un párrafo. 

c. En un párrafo, describa la manera en que los miembros de su grupo de análisis de 
sistemas pueden usar la información de los mensajes de correo electrónico para 
moldear sus proyectos de sistemas para Sawder's. 

d. En las entrevistas con Sid, Ernie y Cari, no ha surgido ninguna mención de proble¬ 
mas en el abasto de consumibles para computadora e impresora. En un párrafo, ex¬ 
pliqué por qué algunos problemas no pueden surgir en las entrevistas y explique el 
valor de examinar los mensajes de correo electrónico y otros memorandos además 
de entrevistar. 

4. "Aquí está el principal manual de políticas que hemos conjuntado al paso de los años 
para los usuarios del sistema", dice Al Bookbinder, al tiempo que sacude el polvo del 
manual y se lo pasa a usted. Al es un tenedor de documentos para el departamento de 
sistemas de Prechter y Gumbel, un fabricante de productos para la salud y la belleza. 
"Todo lo que necesita saber cualquier usuario de cualquier parte del sistema está en lo 
que yo llamo el Libro Azul. Quiero decir que está repleto de políticas. Es tan grande, que 
yo soy el único con una copia completa. Cuesta demasiado reproducirlo". En seguida le 
da usted las gracias a Al y toma el manual. Cuando lo lee, se sorprende por su contenido. 
La mayoría de las páginas empieza con un mensaje como: "Esta página reemplaza a la 
página 23.1 del Vol. II del manual. Deseche las inserciones anteriores; no las use". 

a. Mencione sus observaciones sobre la frecuencia de uso del Libro Azul. 

b. ¿Qué tan sencillas para el usuario son las actualizaciones del manual? Explique su 
respuesta en una frase. 

c. Escriba en un párrafo un comentario sobre el sentido común de tener en un libro 
todas las políticas importantes para todos los usuarios de sistemas. 

d. Sugiera una solución que incluya el uso de manuales de políticas en línea para al¬ 
gunos usuarios. 

5. "Creo que podré recordar la mayor parte de todo lo que él hace", dice Ceci Awll. Ceci 
está a punto de entrevistar a BiffWelldon, vicepresidente de planificación estratégica 
de OK Corral, una cadena de restaurantes con 130 sucursales. "Lo que quiero decir es 
que tengo una buena memoria. De cualquier manera, pienso que es mucho más impor¬ 
tante escuchar lo que él dice que observar lo que hace." Como uno de los miembros de 
su equipo de análisis de sistemas, Ceci ha estado hablando con usted sobre la conve¬ 
niencia de anotar sus observaciones de la oficina y las actividades de Biff durante la 
entrevista. 

a. En un párrafo, convenza a Ceci de que no es suficiente escuchar en las entrevistas 
y que observar y registrar esas observaciones también es importante. 

b. Ceci parece haber aceptado su idea de que la observación es importante pero aún 
no sabe qué observar. Haga una lista de elementos y comportamientos por obser¬ 
var, y en una frase al lado de cada comportamiento, indique qué información debe 
esperar obtener Ceci a través de la observación. 

6. "Somos una compañía progresista, siempre en busca de ser los primeros en la ola del, 
poder. Daremos un giro rápido en cualquier sentido si ello nos da una ventaja sobre la 
competencia, y esto incluye a cada uno de nosotros", dice I. B. Daring, ejecutivo de Mi¬ 
chigan Manufacturing (2M). Usted está entrevistándolo como un paso preliminar en 
un proyecto de sistemas, en el cual los subordinados de Daring han expresado interés. 
Conforme escucha a I. B., da un vistazo alrededor de su oficina y se da cuenta de que la 
mayoría de la información que él ha almacenado en los estantes se puede clasificar co¬ 
mo manuales de procedimientos internos. Además, usted observa una PC en una mesa 
posterior de la oficina de I. B. La pantalla del monitor está cubierta de polvo, y los ma- 
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nuales apilados junto a la PC todavía tienen sus envolturas originales. Aunque usted 
sabe que 2M usa una intranet, no hay ninguna conexión visible en la PC de I. B. En la 
pared que está atrás del enorme escritorio de caoba de I. B. se pueden ver cinco retra¬ 
tos al óleo de los fundadores de 2M, bordeados por una placa de oro que reza el eslo- 
gan corporativo: "Asegúrese de tener la razón, y siga adelante". 

a. ¿Cuál es el discurso o argumento organizacional descrito por I. B. Daring? Escríba¬ 
lo con sus propias palabras. 

b. Mencione los elementos del STROBE que haya observado durante su entrevista 
con I. B. 

c. Al lado de cada elemento del STROBE que haya observado, escriba una frase en 
donde explique cómo lo interpretaría. 

d. Elabore una tabla con el discurso organizacional en la parte inferior izquierda de la 
página y los elementos del STROBE en la parte superior. Usando los símbolos de 
la "lista anecdótica" del STROBE, indique la relación entre el discurso organizacio¬ 
nal descrito por I. B. y cada elemento que usted haya observado (es decir, indique 
si cada elemento del STROBE confirma, contradice, motiva un análisis más deta¬ 
llado, modifica o complementa el discurso]. 

e. Con base en sus observaciones del STROBE y su entrevista, enuncie en un párrafo, 
qué problemas puede anticipar para que I. B. y otros aprueben un nuevo sistema. 
En una frase o dos, explique en qué habría diferido su diagnóstico si usted sólo 
hubiera hablado con I. B. por teléfono o hubiera leído sus comentarios sobre una 
propuesta de sistemas. 


PROYECTOS DE 6RUP0 

1. Suponga que su grupo fungirá como equipo de análisis y diseño de sistemas para un 
proyecto cuyo propósito será computarizar o reforzar la computarización de todos los 
aspectos de negocios de una empresa estadounidense de transportes con alrededor de 
15 años de haber sido fundada, llamada MaverickTransport. Maverick es una compañía 
del tipo LTL (less-than-a-truckload). Los directivos tienen la filosofía justo a tiempo 
(JIT), bajo la cual han formado una sociedad que incluye al cargador, al receptor y al 
transportista (MaverickTransport] con el propósito de transportar y entregar los mate¬ 
riales requeridos justo a tiempo para su uso en la línea de producción. Maverick cuenta 
con 626 tractores para transportar la carga, y tiene 15,000 metros cuadrados de alma¬ 
cén y 7,000 metros cuadrados de oficinas. 

a. Junto con sus compañeros de grupo, desarrolle una lista de fuentes de datos archi¬ 
vados que deben revisar al analizar los requerimientos de información de Maverick. 

b. Cuando esta lista esté completa, diseñe un esquema de muestreo que le permita a 
su grupo darse una idea clara de la compañía sin tener que leer cada documento 
generado durante sus 15 años de historia. 

2. Arregle una visita a una organización local que se esté extendiendo o mejorando sus 
sistemas de información. Para permitir que su grupo practique los diversos métodos 
de observación descritos en este capítulo, asigne cualquiera de los dos métodos siguien¬ 
tes a cada miembro del equipo: (1) desarrollar el guión del analista, o (2) utilizar el 
STROBE. Muchas de estas estrategias se pueden utilizar durante las entrevistas uno a 
uno, mientras que algunas requieren reuniones organizacionales formales. Procure 
cumplir diversos objetivos durante su visita a la organización programándola para un 
momento apropiado, que les permita a todos los miembros del equipo practicar el mé¬ 
todo de observación que les hayan asignado. El uso de diversos métodos como las entre¬ 
vistas y la observación (con frecuencia simultáneamente] es la única forma redituable 
de obtener un verdadero y oportuno panorama de los requerimientos de información de 
la organización. 

3. Después de completar el proyecto 2, los miembros de su grupo deben reunirse y discu¬ 
tir sus conclusiones. ¿Encontraron alguna sorpresa? ¿La información recopilada a través 
de la observación confirma, contradice o niega lo que se dijo en las entrevistas? ¿Entra- 
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ron en conflicto directo cualquiera de los resultados obtenidos mediante los métodos 
de observación? En grupo, desarrollen una lista de maneras para resolver cualquier in¬ 
formación confusa (por ejemplo, mediante entrevistas de seguimiento}. 
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VER.ES CREER 


"Chip, sé que las entrevistas tomaron mucho tiempo, pero valieron la pena", dice Anna de¬ 
fensivamente al tiempo que Chip entra en su oficina con expresión de preocupación. 

"Estoy seguro de eso", dice Chip. "Realmente causaste una buena impresión en ellos. 
Algunas personas me han detenido en el vestíbulo y me han dicho que se alegran de que es¬ 
temos trabajando en el nuevo sistema. No estoy preocupado por las entrevistas en sí. Pero 
estaba preocupado porque no tuvimos tiempo para discutir las observaciones antes de que 
las hicieras." 

"No te preocupes, estuve muy atenta en todo", ríe Anna. "Utilicé una técnica llamada 
STROBE, u Observación Estructurada del Entorno, para ver sistemáticamente el habitat de 
nuestros tomadores de decisiones. Te interesarán estas notas que tomé sobre cada persona 
que entrevisté", dice Anna, al momento que le entrega a Chip sus observaciones por escrito 
y bien organizadas de cada entrevista. 



EJERCICIOS 

Estos ejercicios requieren que usted visite el sitio Web para obtener observaciones de las 
oficinas de los tomadores de decisiones. Por favor visite el sitio Web de este libro y busque 
"CPU Observations of Decisión Makers' Offices" ("Observaciones de la CPU acerca de las 
Oficinas de los Tomadores de Decisiones"). 

E-l. Con base en las observaciones que redactó Anna de la oficina y la vestimenta de Dot, 
use la técnica STROBE para analizar a Dot como tomadora de decisiones. En dos pá¬ 
rrafos, compare y contraste lo que aprendió de la entrevista con Dot y lo que apren¬ 
dió por medio de la técnica STROBE. 

E-2. Después de examinar las observaciones que redactó Anna acerca de la oficina de Míke 
Crowe, use la técnica STROBE para analizar a Mike como tomador de decisiones. 
¿Qué diferencias (si las hubo] encontró entre su entrevista con Mike y las observaciones 
de Anna acerca de Mike? Explique su respuesta en dos párrafos. 

E-3. Use la técnica STROBE para analizar las observaciones que redactó Anna sobre Cher 
Ware y Paige Prynter. Use dos párrafos para comparar y contrastar el estilo de toma de 
decisiones de cada persona tal como lo revelan sus oficinas y vestimentas. 

E-4. Use la técnica STROBE para analizar las observaciones que redactó Anna sobre Hy 
Perteks. Ahora compare su análisis con la entrevista de Hy. Use dos párrafos para dis¬ 
cutir si la técnica STROBE confirma, niega, revierte o sirve como una señal para inda¬ 
gar con más detalle lo expresado por Hy. (Incluya cualquier pregunta adicional que le 
plantearía a Hy para aclarar su interpretación.} 
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PROGRAMACIÓN EXTREMA 
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OBJETIVOS DE APRENDIZAJE --' • 1" ' ^ \- 

Una vez que haya dominado el material de este capitulo, podrá: 
í. Entender los cuatro modelos principales de elaboración de prototipos. 

2. Usar la elaboración de prototipos para la recopilación de los requerimientos de información. 

3. Comprender el concepto de RAO para usarlo en la : recopilación de requerimientos de : información: 
y el diseño de interfaces. 

4. Entender la programación extrema y las prácticas esenciales que lo diferencian de otras 

metodologías de desarrollo. 'y Vr*>l 

5. Apreciar la importancia de los valores que son críticos para la programación extrema 

y la modelación ágil. ' si f 
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ELABORACION DE PROTOTIPOS 

Como analista de sistemas que presenta un prototipo del sistema de información, usted está 
bastante interesado en las reacciones de los usuarios y los directivos de la organización hacia el 
prototipo. Usted desea saber detalladamente cómo reaccionarán al trabajar con el prototipo y 
qué tan bien satisfarán sus necesidades las características del sistema a partir de las cuales se ela- 






























boro el prototipo. Las reacciones se recopilan a través de la observación, las entrevistas y las ho¬ 
jas de retroalimentación (posiblemente los cuestionarios) diseñados para obtener la opinión de 
cada persona sobre el prototipo después de que interactúan con él. 

La información recopilada en la fase de elaboración de prototipos permite al analista 
establecer las prioridades y cambiar el rumbo de los planes a bajo costo, con un mínimo 
de molestias. Debido a esta característica, la elaboración de prototipos y la planeación van de 
la mano. 


CLASES DE PROTOTIPOS 

La palabra prototipo se usa de muchas formas diferentes. En lugar de intentar sintetizar to¬ 
dos estos usos en una sola definición o de tratar de convenir en un enfoque correcto al tema 
un tanto polémico de la elaboración de prototipos, ilustramos la manera en que cada una de 
varias concepciones de la elaboración de prototipos se puede aplicar convenientemente en 
una situación particular, como se muestra en la figura 6.1. 

Prototipo corregido La primera clase de elaboración de prototipos tiene que ver con la cons¬ 
trucción de un sistema que funciona pero se corrige simultáneamente. En la ingeniería a este 
enfoque se le llama elaboración de una tabla experimental: la creación, en una tableta de prue¬ 
bas, de un modelo funcional de un circuito integrado (que en la vida real sería microscópico). 
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Un ejemplo en sistemas de información es un modelo funcional que tiene todas las ca¬ 
racterísticas necesarias pero es ineficiente. En este ejemplo de elaboración de prototipos, los 
usuarios pueden interactuar con el sistema, acostumbrándose a la interfaz y los tipos de sali¬ 
das disponibles. Sin embargo, la recuperación y almacenamiento de información podrían 
ser ineficientes, debido a que los programas se escribieron rápidamente con el objetivo de ser 
funcionales en lugar de eficaces. 

Prototipo no funcional El segundo tipo de prototipo es un modelo no funcional a escala con¬ 
figurado para probar ciertos aspectos del diseño. Un ejemplo de este enfoque es un modelo a 
escala completa de un automóvil que se usa para pruebas en un túnel de viento. El tamaño y for¬ 
ma del automóvil son precisos, pero el automóvil no es funcional. En este caso sólo se incluyen 
las características del automóvil que son fundamentales para la prueba en el túnel de viento. 

Un modelo no funcional a escala de un sistema de información podría producirse cuan¬ 
do la codificación requerida por las aplicaciones es demasiado extensa para incluirse en el 
prototipo pero cuando se puede conseguir una idea útil del sistema a través de la elaboración 
de un prototipo de la entrada y la salida. En este caso, el procesamiento, debido al excesivo 
costo y el tiempo requerido, no podría incluirse en el prototipo. Sin embargo, aún se podrían 
tomar algunas decisiones sobre la utilidad del sistema con base en la entrada y la salida in¬ 
cluidas en el prototipo. 

Primer prototipo de una serie Un tercer tipo de prototipos involucra la creación de un pri¬ 
mer modelo a escala completa de un sistema, con frecuencia llamado piloto. Un ejemplo es 
la elaboración de un prototipo del primer avión de una serie. El prototipo es completamen¬ 
te funcional y es una materialización de lo que el diseñador espera será una serie de aviones 
con características idénticas. 

Este tipo de elaboración de prototipos es útil cuando se planean muchas instalaciones 
del mismo sistema de información. El modelo funcional a escala completa permite a los 
usuarios experimentar la interacción real con el nuevo sistema, pero minimiza el costo de 
superar cualquier problema que se presente. La creación de un modelo funcional es uno 
de los tipos de elaboración de prototipos que se hace con RAD, tratado más adelante en 
este capítulo. 

Por ejemplo, cuando una cadena de tiendas de abarrotes minoristas considera el uso del 
EDI (intercambio electrónico de datos) para comprobar los envíos de los proveedores a varias 
tiendas, se podría instalar un modelo a escala completa en una tienda para resolver cualquier 
problema antes de que el sistema se implemente en todas las demás tiendas. Otro ejemplo es 
el de las instalaciones bancarias para la transferencia electrónica de fondos. Primero, se instala 
un prototipo a escala completa en una o dos sucursales, y si tiene éxito, se instalan los duplica¬ 
dos en todas las sucursales con base en los patrones de uso de los clientes y en otros factores 
importantes. 

Prototipo de características seleccionadas Una cuarta concepción de la elaboración de pro¬ 
totipos involucra la creación de un modelo funcional que incluya algunas, pero no todas, 
de las características que tendrá el sistema final. Una analogía sería que un nuevo centro co¬ 
mercial minorista abriera antes de que se terminara la construcción de todas las tiendas. 

Cuando se elaboran prototipos de los sistemas de información de esta manera, se inclu¬ 
yen algunas de las características principales, aunque no todas. Por ejemplo, en la pantalla 
podría aparecer un menú del sistema que muestre seis características: agregar un registro, 
actualizar un registro, eliminar un registro, buscar una palabra clave en un registro, listar un re¬ 
gistro o examinar un registro. Sin embargo, en el prototipo del sistema tal vez sólo estén dis¬ 
ponibles tres de las seis características, de manera que el usuario podría agregar un registro 
(característica 1), eliminar un registro (característica 3} y listar un registro (característica 5). 

Cuando se recurre a este tipo de elaboración de prototipos, el sistema se completa por mó¬ 
dulos de forma que si las características que se incluyen en los prototipos se evalúan exitosa¬ 
mente, se puedan incorporar en el sistema final más grande sin necesidad de realizar demasiado 
esfuerzo en la interacción. Los prototipos hechos de esta forma son parte del sistema real. No 
son sólo un modelo como en el caso de los prototipos no funcionales que se describieron antes. 
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ELABORACIÓN DE PROTOTIPOS COMO UNA ALTERNATIVA AL CICLO DE VIDA 
DEL DESARROLLO DE SISTEMAS 

Algunos analistas argumentan que la elaboración de prototipos se debe considerar como 
una alternativa para el ciclo de vida del desarrollo de sistemas (SDLC). Recuerde que el 
SDLC, tratado en el capítulo 1, es un enfoque lógico y sistemático que se sigue en el desa¬ 
rrollo de sistemas de información. 

Las quejas relativas al proceso del SDLC se centran en dos preocupaciones interrela¬ 
cionadas. La primera preocupación es todo el tiempo que se requiere para pasar por el ciclo 
de vida del desarrollo. Conforme aumenta la inversión de tiempo del analista, el costo del 
sistema entregado se incrementa proporcionalmente. 

La segunda preocupación sobre el uso del SDLC es que los requerimientos del usuario 
cambian a través del tiempo. Los requerimientos del usuario evolucionan durante el conside¬ 
rable intervalo existente entre el análisis de los requerimientos del usuario y la fecha en que se 
entrega el sistema final. Por lo tanto, debido al extenso ciclo del desarrollo, el sistema resultan¬ 
te podría ser criticado por abordar deficientemente los requerimientos de información del 
usuario actual. 

Un corolario al problema de mantenerse al tanto de los requerimientos de información del 
usuario es la teoría de que los usuarios realmente no saben lo que hacen o no lo desean sino 
hasta que ven algo tangible. En el SDLC tradicional, una vez que se entrega un sistema, con 
frecuencia es demasiado tarde para modificarlo. 

Para resolver estos problemas, algunos analistas proponen la elaboración de prototipos 
como una alternativa al ciclo de vida del desarrollo de sistemas. Cuando la elaboración de 
prototipos se usa de esta forma, el analista reduce efectivamente el tiempo entre la deter¬ 
minación de los requerimientos de información y la entrega de un sistema funcional. Además, 
el uso de la elaboración de prototipos en lugar del SDLC tradicional podría resolver algu¬ 
nos problemas cómo el de identificar con precisión los requerimientos de información del 
usuario. 

Entre las desventajas de sustituir el SDLC por la elaboración de prototipos está la de la 
configuración prematura de un sistema antes de que el problema u oportunidad en cuestión 
se entienda completamente. También, el uso de la elaboración de prototipos como una 
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alternativa podría producir un sistema aceptado por grupos específicos de usuarios pero 
inadecuado para las necesidades globales del sistema. 

El enfoque que apoyamos aquí es usar la elaboración de prototipos como una parte del 
SDLC tradicional. Desde esta perspectiva, la elaboración de prototipos se considera como 
un método adicional y especializado para determinar los requerimientos de información de 
los usuarios. 


CÓMO DESARROLLAR UN PROTOTIPO 

Los lincamientos de esta sección para desarrollar un prototipo son avanzados. El término 
elaboración de prototipos se interpreta en el sentido de la última definición que se explicó, es 
decir, un prototipo de características seleccionadas que incluirá algunas pero no todas las ca¬ 
racterísticas; uno que, si tiene éxito, será parte del sistema final que se entregue. 

Como se ilustra en la figura 6.2, la elaboración de prototipos es una excelente forma de 
obtener retroalimentación sobre el sistema propuesto y sobre la facilidad con que está cum¬ 
pliendo las necesidades de información de sus usuarios. El primer paso de la elaboración de 
prototipos es estimar los costos necesarios para la construcción de un módulo del sistema. 



Archivó dél cliente 


Nombre del clientd. L 


Dirección: 
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Cólinentaiins: 


Archivo del cliente 
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del usuario da como resultado 
pantallas mejoradas: que. 
satisfacen mejor los . 
requerimientos del usuario. 
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Si los costos del tiempo de programadores y analistas y los del equipo que utilizarán 
están dentro del presupuesto, se puede proceder a la elaboración del prototipo. La elabora¬ 
ción de prototipos es una excelente forma de facilitar la integración del sistema de infor¬ 
mación con el sistema principal de la organización. 


LINEAÜENTQS PARA DESARROLLAR UN PROTOTIPO 

Una vez que se ha tomado la decisión de elaborar un prototipo, se deben observar cuatro li¬ 
ncamientos principales al integrar la elaboración de prototipos con la fase de determinación 
de requerimientos del SDLC: 

1. Trabajar en módulos manejables. 

2. Construir rápidamente el prototipo. 

3. Modificar el prototipo en iteraciones sucesivas. 

4. Poner énfasis en la interfaz de usuario. 

Como puede ver, los lincamientos sugieren acciones relativas al prototipo que necesariamente 
se interrelacionan. Cada uno de los lincamientos se explica en las subsecciones siguientes. 

El trabajo en módulos manejables Cuando el prototipo de algunas de las características de un 
sistema se integra para formar un modelo funcional, es indispensable que el analista trabaje en 
módulos manejables. Una ventaja evidente de la elaboración de prototipos es que no es nece¬ 
sario ni deseable construir un sistema operativo completo para los propósitos del prototipo. 

Un módulo manejable es aquel que permite a los usuarios interactuar con sus caracterís¬ 
ticas clave pero que se puede construir de forma separada de otros módulos del sistema. Las 
características del módulo que se juzgan de menor importancia se omiten intencionalmente 
en el prototipo inicial. 

Construcción rápida del prototipo La rapidez es esencial para la elaboración exitosa del 
prototipo de un sistema de información. Recuerde que una de las quejas expresadas en con¬ 
tra del SDLC tradicional es que el intervalo entre la determinación de requerimientos y la 
entrega de un sistema completo es demasiado largo para satisfacer eficazmente las cambian¬ 
tes necesidades del usuario. 

Los analistas pueden usar la elaboración de prototipos con el fin de reducir esta brecha 
utilizando las técnicas tradicionales de recopilación de información para determinar con pre¬ 
cisión los requerimientos de información que surjan sobre la marcha, y a continuación tomar 
rápidamente las decisiones que den lugar a un modelo funcional. De hecho, el usuario ve y 
utiliza el sistema muy temprano en el SDLC en lugar de esperar hasta que el sistema se ter¬ 
mine para practicar con él. 

La preparación de un prototipo operacional, con rapidez y en las etapas tempranas del 
SDLC, permite al analista comprender mejor cómo desarrollar el resto del proyecto. Al mos¬ 
trar a los usuarios en las primeras etapas del proceso cómo se ejecutan en la realidad algunas 
partes del sistema, la elaboración rápida de prototipos evita que se dediquen demasiados re¬ 
cursos a un proyecto que a la larga podría ser imposible de concretar. Más adelante, cuando se 
explique el RAD, usted verá nuevamente la importancia de la construcción rápida de sistemas. 


Modificación del prototipo Un tercer lincamiento para desarrollar el prototipo es que su 
construcción debe soportar modificaciones. Hacer modificable el prototipo significa crearlo 
en módulos que no sean demasiado interdependientes. Si se observa este lincamiento, se en¬ 
contrará menos resistencia cuando sea necesario realizar cambios al prototipo. 

Generalmente, el prototipo se modifica varias veces al pasar por diversas iteraciones. 
Los cambios en el prototipo deben propiciar que el sistema se acerque cada vez más a lo 
que los usuarios consideren importante. Cada modificación necesita otra evaluación por 
parte de los usuarios. 

El prototipo no es un sistema terminado. Abordar la fase de elaboración de prototipos 
con la idea de que el prototipo requerirá modificaciones es una actitud positiva que de¬ 
muestra a los usuarios cuan necesaria es su retroalimentación para mejorar el sistema. 
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¿LA ELABORACIÓN DE PROTOTIPOS ES LO MEJOR? 


Al tiempo que formula una respuesta para Paul, usted piensa en las 
pocas semanas que ha trabajado en Pyramid, Inc. Usted cree que los pro- 


"Como usted sabe, somos un grupo entusiasta. Todavía no somos una 
dinastía, pero nos estamos esforzando para serlo”, le dice Paul LeGon. 
Paul (a quien le presentamos en la Oportunidad deconsultoría 2,3), con24 
años de edad, es el "rey joven" de Pyramid, Inc., una pequeña empresa edi¬ 
torial Independiente pero exitosa que se especializa en libros con cubierta 
rústica sobre temas poco convencionales. Como analista de sistemas,; 
usted ha sido contratado por Pyramid, Inc., para colaboraren el desarrollo 
de un sistema de Información computerizado para el manejo de la distribu¬ 
ción y el inventario del almacén, v 

"Estamos contratando a muchos trabajadores", continúa Paul, para 
convencerlo de la importancia del proyecto de Pyramid; "Y sentimos que 
Pyramid está perfectamente posicionado en nuestros mercados del nor¬ 
te, el sur, el este y el oeste.". , : : : z : 

"Mr ayudante,.Cell Toom,y,yo hemos estado trabajando como esclavos, 
pensando en el nuevo sistema. Y hemos concluido que lo que realmente 
necesitamos es un prototipo. De hecho,: hemos; invéstigado mucho,ycada 
vez estamos más fascinados con la ideal" 


blemas;dé negocios quesu sistema deinformación debe resolver son muy 
sencillos. También sabe que las personas de la compañía tienen un presu¬ 
puesto limitado y no se pueden daré] lujo de gastar como reyes. En realidad, 
el proyecto entero es bastante pequeño. : ; 

Geil, basándose en lo que Pauhha comentado, dice: "No pretende¬ 
mos Involucrarnos demasiado en esto A pero creemos que la elabora¬ 
ción de prototipos representa la nueva tendencia. Y ahfes donde to¬ 
dos queremos estar. Sabemos que necesitamos un prototipo. ¿Lo hemos 
convencido?",; ■ . v .. - 

Con base en el entusiasmo de Paul y Ceil por la elaboración de proto¬ 
tipos y lo que usted sabe de las necesidades de Pyramid, ¿apoyaría usted 
la construcción de un prototipo? ¿Por qué sí o porqué no? Redacte una 
carta en donde explique su decisión y mándesela a Paul LeGon y Cell 
Toom; Sustente su decisión argumentando los criterios globales que se 
deben cumplir para justificar la elaboración de prototipos. 


Énfasis en la interfaz de usuario La interfaz de usuario con el prototipo (y posteriormen¬ 
te con el sistema) es muy importante. Puesto que en realidad su principal objetivo con el 
prototipo es conseguir que los usuarios expresen mucho mejor sus requerimientos de informa¬ 
ción, éstos deben interactuar fácilmente con el prototipo del sistema. Para muchos usuarios 
la interfaz es el sistema. Esto no debe representar un obstáculo. 

Aunque no se desarrollarán muchos aspectos del sistema en el prototipo, la interfaz de 
usuario se debe desarrollar lo mejor posible para permitir a los usuarios una rápida com¬ 
prensión del sistema y no sentirse desorientados. Los sistemas interactivos en línea que usan 
interfaces gráficas son particularmente apropiados para los prototipos. En el capítulo 15 se 
describen en detalle las consideraciones que son importantes en el diseño de la interfaz de 


DESVENTAJAS DE LA ELABORACION DE PROTOTIPOS 

Como en cualquier técnica de recopilación de información, la elaboración de prototipos 
tiene varias desventajas. La primera es que puede ser bastante difícil manejar la elaboración 
de prototipos como un proyecto en el esfuerzo de sistemas más grandes. La segunda des¬ 
ventaja es que los usuarios y los analistas podrían adoptar un prototipo como si fuera un siste¬ 
ma final cuando de hecho es deficiente y su propósito nunca fue el de servir como sistema 
terminado. 

El analista necesita sopesar estas desventajas contra las ventajas conocidas al decidir si 
hace el prototipo, cuándo lo hace y de qué partes del sistema lo hace. 


VENTAJAS DE LA ELABORACION DE PROTOTIPOS 

La elaboración de prototipos no es necesaria o apropiada en todos los proyectos de sistemas, 
como hemos visto. Sin embargo, también se deben considerar las ventajas al momento de deci¬ 
dir si se hace el prototipo. Las tres ventajas principales de la elaboración de prototipos son la 
posibilidad de modificar el sistema en las primeras etapas del desarrollo, la oportunidad de 
suspender el desarrollo de un sistema que no sea funcional y la posibilidad de desarrollar 
un sistema que se acerque más a satisfacer las necesidades y expectativas de los usuarios. 
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EL CRIADERO DE PECES 


"Tan sólo tengamos un poco de paciencia. Creo que necesitamos incor¬ 
porar algunas características más, antes de entregarles el prototipo. De 
otra manera, este prototipo se hundirá por completo", dice Sam Monroe, un 
miembro de su equipo de análisis de sistemas. Los cuatro miembros del 
equipo están enfrascados en una reunión convocada con precipitación, y 
discuten acerca del prototipo que desarrollan para un sistema de informa¬ 
ción que servirá a los gerentes para supervisar y controlar la temperatura 
del agua, la cantidad de peces puestos a la venta y otros factores en un 
criadero comercial de peces." 

"Ya tienen bastante que hacer. ¡Vaya!, el sistema empezó con cuatro 
características y ya llevamos nueve. Siento como si estuviéramos nadan¬ 
do contra la corriente. Ellos no necesitan todo esto. Incluso ni lo quieren 1 ', 
sostiene Belle Uga, segundo miembro del equipo de análisis de sistemas, 
"No quiero polemizar, pero opino que tan sólo les demos lo elemental. Ya 
tenemos suficiente de qué preocuparnos así como están las cosas.” 

'Yo creo que Monroe tiene razón”, opina Wally Ide, un tercer miembro 
del equipo, contraponiéndose tin poco a Belle. "Tenemos que darles lo me¬ 
jor que podamos, aun cuando esto signifique retrasar el prototipo unas 
cuantas semanas más de lo que prometimos." : 

"De acuerdo", responde Belle con cautela,,"pero quiero que ustedes 
dos expliquen a los gerentes del criadero por qué no les estamos entre¬ 
gando el prototipo. Yo no quiero hacerlo. Y no estoy seguro de que ellos 
muerdan el anzuelo tan fácilmente". 

Monroe contesta: "Bueno, creo que'podemos hacerlo, pero tal vez no 
consigamos un buen trato al retrasarnos más de lo que queremos. No quie¬ 
ro complicar las cosas”. : 


Wally coincide: "Es cierto. ¿Por qué mostrar nuestros errores a todos? 
Además, cuando vean el prototipo,: se olvidarán de cualquier queja que 
tengan?;Les encantará". 

Belle saca de su cuaderno un memorando de su última reunión 
con los gerentes del criadero y lo lee'en voz alta. "Agenda de la reu¬ 
nión del 22 de septiembre. 'Elaboración de prototipos: la importancia 
del desarrollo rápido, conjuntar al equipo analista de usuarios-obte¬ 
ner una rápida retroallmentación para hacer las modificaciones..." 1 
La voz de Belle se desvanece, 1 omitiendo los últimos puntos de la 
agenda. Después de estos comentarios, Monroe e Ide se miran des¬ 
consoladamente. 

Monroe habla primero: "Supongo que hicimos el intento de entusias¬ 
mar a todos para que esperaran un prototipo, y se involucraran desde el 
primer día”? Percatándose de que usted ha permanecido en silencio, 
Monroe continúa: "Pero las aguas aún están agitadas. ¿Qué crees que 
debemos hacer 7 "; le pregunta a usted, . 

En su calidad de cuarto miembro del equipo de análisis de sistemas, 
¿qué acciones cree que deban emprenderse? En uno o dos párrafos, en¬ 
víe un mensaje de correo electrónico a sus compañeros de equipo, con la 
respuesta a las siguientes preguntas: ¿Deben incorporarse más caracte¬ 
rísticas al prototipo derisistema del criadero antes de entregarlo a los 
¿gerentes para que experimenten con él? ¿Qué tan Importante es el desa¬ 
rrollo rápido del prototipo? ¿Cuáles son las; ventajas y desventajas de 
Incorporar más características ai prototipo o de entregarle ai cliente un 
prototipo más elemental que el que.se .le prometió? Finalice su mensaje 
con una recomendación, , : 


EL PAPEL DEL USUARIO EN LA ELABORACION DE PROTOTIPOS . 

El papel del usuario en la elaboración de prototipos se puede resumir en dos palabras: inter¬ 
vención honrada. Sin la intervención del usuario hay poca razón para elaborar el prototipo. 
Los comportamientos precisos y necesarios para interactuar con un prototipo pueden 
variar, pero está claro que el usuario es fundamental en el proceso de la elaboración de 
prototipos. Comprendiendo la importancia que tiene el usuario en el éxito del proceso, los 
miembros del equipo de análisis de sistemas deben propiciar y recibir de buena manera la 
retroalimentación y deben evitar su propia resistencia natural a cambiar el prototipo. 


INTERACCION CON EL PROTOTIPO 

Hay tres formas principales en las que un usuario puede ayudar en la elaboración de pro¬ 
totipos: 

1. Experimentando con el prototipo. 

2. Dando reacciones sinceras sobre el prototipo. 

3. Sugiriendo adiciones o eliminaciones al prototipo. 

Los usuarios deben tener libertad para experimentar con el prototipo. En contraste 
con una simple lista de características de sistemas, el prototipo permite a los usuarios la in¬ 
teracción real. Una forma de facilitar esta interacción es instalar un prototipo en un sitio 
Web interactivo. 
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DHSARROIiORÁPIDODHAPLICACIONHS 

El desarrollo rápido de aplicaciones (RAD) es un enfoque orientado a objetos para el desa¬ 
rrollo de sistemas que incluye un método de desarrollo así como también herramientas de 
software. Es lógico discutir RAD y la elaboración de prototipos en el mismo capítulo, debi¬ 
do a que están conceptualmente muy unidos. Ambos tienen como meta la reducción del 
tiempo que generalmente se necesita en un SDLC tradicional entre el diseño y la imple- 
mentación del sistema de información. Finalmente, el RAD y la elaboración de prototipos 
se enfocan en satisfacer más de cerca los requerimientos cambiantes de los negocios. Una 
vez que ha aprendido los conceptos de la elaboración de prototipos, es mucho más fácil en¬ 
tender la esencia del RAD, que se puede considerar como una implementación específica 
de la elaboración de prototipos. 

Algunos desabolladores están considerando al RAD como un enfoque útil para los 
nuevos entornos de comercio electrónico basados en la Web, en el cual podría ser importan¬ 
te el estatus de primero en tomar la iniciativa de un negocio. En otras palabras, para poner 
una aplicación en la Web antes que sus competidores, las empresas podrían requerir que su 
equipo de desarrollo experimente con el RAD. 


FASES DEL RAD 

Hay tres fases amplias del RAD que vinculan a usuarios y analistas en la evaluación, diseño 
e implementación. La figura 6.4 describe estas fases. Observe que el RAD involucra a los 
usuarios en cada parte del esfuerzo de desarrollo, con una intensa participación en la parte 
de negocios del diseño. 

Fase de planeación de requerimientos En esta fase, usuarios y analistas se reúnen para 
identificar los objetivos de la aplicación o sistema y para identificar los requerimientos de 
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información que surgen de dichos objetivos. Esta fase requiere que ambos grupos se involu¬ 
cren intensamente; no se trata simplemente de firmar una propuesta o documento. Además, 
esto podría involucrar a usuarios de los diferentes niveles de la organización (como se trató 
en el capítulo 2). En la fase de planeación de requerimientos, cuando aún se están determi¬ 
nando los requerimientos de información, usted podría estar trabajando con el director de 
información (si es una organización grande) así como también con la gente de planeación 
estratégica, sobre todo si usted está trabajando con una aplicación de comercio electrónico 
cuyo propósito es impulsar los objetivos estratégicos de la organización. La orientación en 
esta fase tiene el objetivo de resolver los problemas de negocios. Aunque algunas de las so¬ 
luciones propuestas podrían surgir de la tecnología de información disponible, el enfoque 
siempre será alcanzar los objetivos del negocio. 

Taller de diseño del RAD El proceso de diseñar y refinar los prototipos se puede represen¬ 
tar mejor como un taller. Cuando imagina un taller, sabe que la participación es intensa, no 
pasiva, y que generalmente se hace con las manos. Normalmente los usuarios están sentados en 
mesas redondas o en una configuración en forma de U de sillas con escritorios adheridos 
donde cada persona puede ver a otra y donde hay espacio para trabajar con una computadora 
portátil. Si usted es bastante afortunado para disponer de un salón para sistemas de apoyo 
a la toma de decisiones en grupo (GDSS) en la compañía o a través de una universidad local, 
utilícelo para conducir por lo menos una parte de su taller de diseño de RAD. 

Durante el taller de diseño del RAD, los usuarios responden a los prototipos operativos 
reales y los analistas refinan los módulos diseñados (utilizando algunas de las herramientas de 
software que se mencionan más adelante) basados en las respuestas del usuario. El formato 
del taller es muy emocionante y estimulante, y si están presentes los usuarios y los analistas 
experimentados, no hay ninguna duda de que este esfuerzo creativo puede impulsar el desa¬ 
rrollo a gran velocidad. 

Fase de implementación En la figura anterior, puede ver que los analistas están trabajan¬ 
do intensamente con los usuarios durante el taller para diseñar los aspectos del negocio o no 
técnicos del sistema. Tan pronto como sean convenidos estos aspectos y los sistemas sean 
construidos y se refinen, los nuevos sistemas, o parte de ellos, son probados e introducidos 
en la organización. Debido a que el RAD se puede usar para crear las nuevas aplicaciones de 
comercio electrónico para las cuales no hay ningún sistema viejo, por lo general no se nece¬ 
sita ejecutar los sistemas viejos y nuevos en paralelo antes de la implementación (además 
que no hay forma real de hacerlo). 

En este punto, el taller de diseño del RAD habrá generado el interés, sentido de perte¬ 
nencia del usuario y la aceptación de la nueva aplicación. Generalmente, el cambio que se 
produce de esta forma es mucho menos doloroso que cuando un sistema se entrega con po¬ 
ca o ninguna participación del usuario. 
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Enfoques pioneros de Martín para el RAD En la figura 6.5 usted puede ver nuestra conceptua- 
lización de las fases originales del RAD de James Martin. En la primera fase Martin explica la 
planeación de requerimientos. Aquí los usuarios de alto nivel deciden qué funciones debe 
incluir la aplicación. 

En la segunda fase, llamada fase de diseño del usuario, Martin caracteriza a los usuarios 
como ocupados en discutir los aspectos no técnicos del diseño del sistema, con la ayuda de 
los analistas. La fase del taller de diseño del RAD incorpora las fases del usuario y la de cons¬ 
trucción en una, debido a que la naturaleza muy interactiva y visual del proceso de diseño y 
refinación están ocurriendo de una forma interactiva y participativa. 

En la fase de construcción se realizan muchas actividades diferentes. Cualesquier diseños 
que se creen en la fase anterior se mejoran más con las herramientas del RAD. Tan pronto 
como las nuevas funciones están disponibles, se muestran a los usuarios para la interac¬ 
ción, comentarios y revisión. Con las herramientas del RAD, los analistas pueden hacer cam¬ 
bios continuos en el diseño de las aplicaciones. 

En la cuarta y última fase de Martin, la fase de cierre, la aplicación recientemente desa¬ 
rrollada reemplazará a la anterior. Mientras está ejecutándose en paralelo con la aplicación 
anterior, la nueva se prueba, los usuarios son entrenados y los procedimientos de la organi¬ 
zación se cambian antes de que ocurra el cierre. 

Herramientas de software para el RAD Como usted podría esperar, por lo regular las herra¬ 
mientas de software para el RAD son las más nuevas, con frecuencia orientadas a objetos. 
Algunos ejemplos son programas muy conocidos tales como Microsoft Access, Microsoft 
Visual Basic, Visual C++ y Microsoft .NET. (Véase el capítulo 18 para una explicación más 
detallada del enfoque orientado a objetos.) 

Una forma en que las herramientas difieren entre sí está en sus capacidades para dar so¬ 
porte a las aplicaciones cliente/servidor (por ejemplo, MS Access no da soporte. Visual Basic 
sí lo da) así como también su facilidad de uso y el nivel de conocimientos de programación 
que se requieren. La mayoría de las aplicaciones del RAD se usan para aplicaciones peque¬ 
ñas basadas en PC, aunque su verdadero poder podría radicar en las aplicaciones cliente/ 
servidor que necesitan ejecutarse a través de múltiples plataformas. 

Aunque hay identificadas casi tantas fases diferentes del RAD así como hay analis¬ 
tas, las cuatro fases propuestas por Martin —planeación de requerimientos, diseño del 
usuario, la construcción y cierre— son útiles. Examinemos cada una con más detalle, 
comparándolas y contrastándolas con las características de la elaboración de prototipos 
clásica y el SDLC tradicional. 


RAD EN COMPARACION CON EL SDLC 

En la figura 6.6 puede comparar las fases del SDLC con aquellas detalladas para el RAD al 
principio de esta sección. Observe que el principal propósito del RAD es acortar el SDLC 
y de esta forma responder más rápidamente a los requerimientos de información dinámicos 
de las organizaciones. El SDLC toma un enfoque más metódico y sistemático que asegura 
la integridad y exactitud y tiene como propósito la creación de sistemas que se integran 
bien en los procedimientos estándar de negocio y en la cultura. 

La fase del taller de diseño del RAD difiere de las fases de diseño estándar del SDLC, 
debido a que las herramientas de software del RAD se usan para generar pantallas y exhibir 
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el flujo global del funcionamiento de la aplicación. Así, cuando los usuarios aprueban este 
diseño, están conviniendo en una representación del modelo visual, no sólo en un diseño 
conceptual representado en papel, como tradicionalmente se hace. 

La fase de implementación del RAD es, en muchas formas, menos estresante que otras, 
debido a que los usuarios han ayudado a diseñar los aspectos de negocios del sistema y saben 
perfectamente qué cambios se harán. Hay pocas sorpresas, y el cambio es algo a lo que se le 
da la bienvenida. Con frecuencia, cuando se utiliza el SDLC y los analistas están separados de 
los usuarios, hay mucho tiempo entre el desarrollo y el diseño. Durante este periodo, los 
requerimientos pueden cambiar y los usuarios se pueden sorprender si el producto final es di¬ 
ferente del que se anticipó durante muchos meses. 
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Cuándo utilizar el RAD En su función de analista, necesita aprender tantos enfoques y 
herramientas como sea posible que lo ayuden a hacer mejor su trabajo. Ciertas aplicacio¬ 
nes y trabajo de sistemas darán lugar a ciertas metodologías. Considere utilizar RAD 
cuando: 

1. su equipo incluya a programadores y analistas que tengan experiencia con él, y 

2. haya razones de negocios urgentes para acelerar una parte del desarrollo de la apli¬ 
cación; o 

3. cuando esté trabajando con una nueva aplicación de comercio electrónico y su equi¬ 
po de desarrollo crea que el negocio puede beneficiarse ampliamente sobre sus compe¬ 
tidores siendo innovador si esta aplicación está entre las primeras en aparecer en la 
Web; o 

4. cuando los usuarios sean maduros y estén altamente comprometidos con las metas or- 
ganizacionales. 


Desventajas del RAD Las dificultades con el RAD, como con otras clases de elaboración 
de prototipos, se originan debido a que los analistas de sistemas intentan apresurar demasiado 
el proyecto. Suponga que se contratan dos carpinteros para construir dos cobertizos de al¬ 
macenamiento para dos vecinos. El primer carpintero sigue la filosofía de SDLC, mientras 
que el segundo la del RAD. 

El primer carpintero es sistemático, cataloga cada herramienta, cada podadora y cada 
uno de los muebles del patio para determinar el tamaño correcto del cobertizo, diseña un 
plano del cobertizo y anota las especificaciones para cada parte de madera y hardware. El 
carpintero construye el cobertizo con poca pérdida y tiene la documentación precisa sobre 
cómo fue construido el cobertizo por si cualquiera quisiera construir otro parecido, reparar¬ 
lo o pintarlo del mismo color. 

El segundo carpintero va directo al proyecto y calcula el tamaño del cobertizo, con¬ 
sigue un camión de madera y hardware, construye una estructura y discute con el dueño 
de la propiedad las modificaciones necesarias si no están disponibles ciertos materiales y 
hace un viaje para devolver la madera que no se usa. El cobertizo se construye rápida¬ 
mente, pero si no se hace un plano, nunca existe la documentación. 


'programación "extrema 

La programación extrema (XP) es un enfoque de desarrollo de software (tratado en el capítu¬ 
lo 3) que adopta lo que generalmente designamos como prácticas de desarrollo de software 
aceptable y las lleva al extremo. Por ejemplo, la retroaÜmentación es importante para los pro¬ 
gramadores, analistas, diseñadores, usuarios y computadoras (como verá en el capítulo 14). 
Así que la programación extrema usa ciclos de retroalimentación cada vez más rápidos e 
intensos, que proporcionan más información. 

La administración de proyectos es importante (como se vio en el capítulo 3), de tal 
manera que la programación extrema intenta definir rápidamente un plan global del sis¬ 
tema, desarrollar y liberar rápidamente el software y posteriormente revisarlo continua¬ 
mente para incorporarle características adicionales. Los programadores, analistas y dise¬ 
ñadores ordinarios que trabajan independientemente y luego integran su trabajo logran 
resultados sólidos; los programadores extremos que trabajan en pareja pueden ser excelen¬ 
tes. Pero la programación extrema no sólo se basa en los resultados. Se basa en los valores, 
principios y prácticas. Ahora examinaremos cómo los valores y principios de XP dan forma 
al desarrollo de sistemas extremos. 


VALORES Y PRINCIPIOS DE LA PROGRAMACIÓN EXTREMA 


Para la programación extrema es importante que se declaren los valores y principios que 
crean el contexto para la colaboración entre programadores y clientes. Para considerarse 
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analista de XP, se debe apegar a los siguientes valores y principios desarrollados por Beck 

[ 2000 ]. 

Cuatro valores de XP Hay cuatro valores que crean un entorno en el cual se pueden servir 
adecuadamente diseñadores y negocios. Debido a que con frecuencia hay una tensión entre lo 
que los diseñadores hacen a corto plazo y lo que es comercialmente deseable a largo plazo, es 
importante que esté consciente de apoyar valores que formarán una base para colaborar jun¬ 
tos en un proyecto de software. Como se muestra en la figura 6.7, los cuatro valores son 
comunicación, sencillez, retroalimentación y valentía. 

Empecemos con la comunicación. Cada esfuerzo humano tiene la posibilidad de fallar en 
la comunicación. Los proyectos de los sistemas que requieren una actualización constante y 
un diseño técnico son especialmente propensos a dichos errores. Agregue a este proyecto fe¬ 
chas límite ajustadas, jerga especializada y el estereotipo de que los programadores prefieren 
hablar con las máquinas que con las personas, y usted tiene los ingredientes para algunos pro¬ 
blemas serios de comunicación. Los proyectos pueden ser retrasados; se puede resolver el 
problema equivocado; se castiga a los programadores incluso por mencionar a los gerentes 
que hay problemas; las personas abandonan o se unen al proyecto a la mitad sin estar al co¬ 
rriente; y así continúa la letanía. 

Prácticas típicas de XP tal como la programación en parejas [colaboración de dos 
programadores, descrita más adelante en el capítulo), estimación de las tareas y las prue¬ 
bas del software, requieren de una buena comunicación. Los problemas se resuelven rá¬ 
pidamente, los agujeros se tapan y la opinión débil se fortalece rápidamente a través de 
la interacción con otros en el equipo. Un instructor de XP, como se describió en el capí¬ 
tulo 3, está presente para observar si alguien ha interrumpido la comunicación y para 
reunirlos. 

El segundo valor de la programación extrema es la simpleza. Cuando estamos trabajan¬ 
do en un proyecto de desarrollo de software, nuestra primera reacción es abrumarnos por la 
complejidad y magnitud de la tarea. Sin embargo, usted no puede correr si no sabe caminar, 
ni caminar si no sabe ponerse de pie. La simpleza en el desarrollo de software significa que 
empezaremos con la cosa más sencilla que podemos hacer. 

La simpleza lleva tiempo, y es algo en lo que el instructor de XP podría ayudarle. El valor 
de XP de simpleza nos pide que hoy hagamos la cosa más sencilla, comprendiendo que ma¬ 
ñana se podría cambiar un poco. Esto requiere un enfoque claro de las metas del proyecto y 
realmente es un valor básico. 

La retroalimentación es el tercer valor básico que es importante para tener un enfo¬ 
que de la programación extrema. Cuando piensa en la retroalimentación en este contex¬ 
to, es bueno considerar que ésta se relaciona con el concepto de tiempo. Una retroalimen¬ 
tación buena y concreta, que es útil para el programador, analista y cliente puede ocurrir 
en segundos, minutos, días, semanas o meses, dependiendo de lo que se necesita, quién es¬ 
tá comunicando y lo que se hará con dicha retroalimentación. Un colega programador po¬ 
dría encontrar un caso de prueba que hiciera que un código que usted escribió fallara. Esto 






podría ocurrir sólo horas antes de la fecha de entrega, pero dicha retroalimentación es 
casi invaluable en lo que se refiere a poder cambiar lo que no está funcionando antes de 
que se acepte y se inserte en el sistema. 

La retroalimentación ocurre cuando los clientes crean pruebas funcionales para todas 
las historias que los programadores habrán de implementar. (Véase más adelante en este 
capítulo las historias del usuario.) La retroalimentación crítica sobre el programa de trabajo 
viene de clientes que comparan la meta del plan con el progreso que se ha tenido. La re¬ 
troalimentación ayuda a los programadores a hacer los ajustes y permite a los negocios tener 
una experiencia a tiempo de lo que el nuevo sistema se parecerá una vez que sea totalmente 
funcional. 

La valentía es el cuarto valor enunciado en la programación extrema. La valentía tiene 
que ver con un nivel de confianza que debe existir en el equipo de desarrollo. Significa que 
no se debe tener miedo de tirar una tarde o un día de programación y empezar de nuevo si 
todo está mal. Significa tomar en cuenta los propios instintos (y resultados de la prueba) 
respecto de lo que funciona y lo que no. 

• La valentía también significa responder a una retroalimentación concreta, tomar una 
decisión basándose en el presentimiento de un compañero de equipo cuando creen que tie¬ 
nen una forma más simple o mejt>r de lograr su meta. La valentía es un valor de alto riesgo 
y de alta recompensa qué anima a la experimentación que el equipo puede tomar de una 
forma más rápida e innovadora para lograr su meta. La valentía significa que usted y sus 
compañeros se tienen suficiente confianza mutua y en sus clientes como para actuar en for¬ 
mas que mejorarán continuamente lo que se está haciendo en el proyecto, aun cuando ello 
requiera tirar el código, reconsiderar las soluciones o, más aún, simplificar los enfoques. La 
valentía también implica que usted, como analista de sistemas, aplique con empeño las prác¬ 
ticas extremas de XR 

Principios básicos de XP En un mundo perfecto, los clientes y su equipo de desarrollo de 
software estarían de acuerdo en todo y no sería necesaria la comunicación. Sabemos que no 
existe el mundo ideal. ¿Pero cómo podemos hacer nuestros proyectos de desarrollo de soft¬ 
ware más parecidos al ideal? Una razón para que esto no ocurra se debe a que hasta ahora 
estamos intentando operar en un sistema poco claro de valores compartidos. Son un buen 
principio, pero realmente no son operativos en el punto en que podamos medir nuestro éxi¬ 
to de forma significativa. De manera que trabajamos para derivar los principios básicos que 
nos pueden ayudar a verificar si lo que estamos haciendo en nuestro proyecto de software 
realmente está midiendo los valores que compartimos. 

Aunque hay alrededor de una docena de principios que podemos derivar de nuestros va¬ 
lores, los principios básicos que describimos son: proporcionar una rápida retroalimentación, 
dar por hecho la sencillez, cambiar progresivamente, aceptar el cambio y alentar el trabajo de 
calidad. En la figura 6.8 se ilustran dichos principios. 
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El principio básico para recordar respecto a la retroalimentación rápida es que para que 
las personas o los sistemas hagan una conexión entre estímulo y reacción, la retroalimenta¬ 
ción debe ocurrir en un intervalo razonablemente corto. Si a una impresora se le termina el 
papel, debe desplegar instantáneamente un mensaje "no hay papel" como retroalimenta¬ 
ción para el usuario, de manera que la situación se pueda remediar y la impresión pueda conti¬ 
nuar. La retroalimentación rápida para el equipo de desarrollo significa que entre más cercano 
sea el tiempo de una acción [codificar una característica derivada de un reporte del usuario) 
al tiempo de la comprobación, más significativa será la retroalimentación (los resultados de 
la prueba}. Entre más pronto en la vida de un sistema éste se ponga en producción (en lugar 
de simplemente estar en desarrollo), mayor será el valor de la retroalimentación para el ne¬ 
gocio al medir si el sistema está cumpliendo sus metas. 

El siguiente principio básico es que el equipo de desarrollo debe adoptar la simpleza. La 
premisa es que alrededor de 90 por ciento de los problemas se puede resolver con absoluta 
sencillez. Observe que esto se contrapone a la mayoría del entrenamiento tradicional, el cual 
les pide a los desarrolladores que planeen para el futuro, entiendan todas las interfaces, y así 
sucesivamente, antes de empezar. La programación extrema dice que la simpleza rige el día, 
y que los programadores deben confiar en su habilidad de agregar la complejidad el próximo 
día si se requiere. Este es un principio muy difícil de dominar para muchos diseñadores. 

El tercer principio que examinamos es el cambio progresivo. Esto significa que usted cons¬ 
tantemente está haciendo el cambio más pequeño posible que aún resulte en una diferencia en 
el esfuerzo de desarrollo. Ningún cambio mayor en el código, el equipo y los requerimientos 
del negocio. Ellos requieren cambio progresivamente, incluso después de que se libera el pro¬ 
ducto. Esto se adapta bien con la idea de XP de evolución. 

Un cuarto principio básico que podemos derivar de los valores de XP es el de aceptar 
el cambio. Necesitamos mantener abiertas todas nuestras opciones, pero, al mismo tiem¬ 
po, necesitamos ser capaces de resolver cualquier obstáculo que se presente. Aunque 
siempre hay pros y contras, sabemos con seguridad que el cambio es bienvenido. Ese dina¬ 
mismo permite que el proyecto siga adelante y anima el espíritu del equipo del proyecto. 
El cambio es bueno. 

El último principio es la noción de alentar el trabajo de calidad. El principio proviene de 
la idea de que todos los participantes deben hacer un trabajo de calidad. Si no hicieran traba¬ 
jo de calidad, ¿por qué considerar ser incluidos en un esfuerzo de programación extrema? El 
punto es hacer el trabajo agradable, trabajar adecuadamente con el equipo y mantener el pro¬ 
yecto sano y salvo. 

Existen algunos principios más que ayudarán a los desarrolladores a saber cómo proceder 
cuando suija una situación particular. En pocas palabras: incluyen la obligación de enseñar a 
aprender; el estímulo para hacer una pequeña inversión inicial de manera que se haga un 
buen, pero no extravagante, trabajo; jugar para ganar, no jugar para evitar perder; y usar expe¬ 
rimentos concretos para probar el trabajo que se está haciendo. 

Otros conceptos importantes que apoyan la programación extrema son la idea de usar la 
comunicación abierta y honrada sin miedo; aprovechar las tendencias naturales de las perso¬ 
nas (querer ser exitoso, interactuar con otros, tener la autonomía en su trabajo, ser parte de un 
equipo ganador, ser confiado, tener en funcionamiento su software); asumir la responsabilidad 
de hacer algo en lugar de ordenarle a alguien que lo haga; adaptar localmente el enfoque que 
está aprendiendo para la programación extrema; y buscar utilizar una medida honrada que no 
pretenda alcanzar una precisión que no existe. 


ACTIVIDADES, RECURSOS Y PRÁCTICAS DE LA PROGRAMACIÓN EXTREMA 

La programación extrema involucra varias actividades que se necesita completar en algún 
momento durante el proceso de desarrollo de XP. Esta sección discute dichas actividades, 
recursos y prácticas que son únicos para la programación extrema. 

Cuatro actividades básicas de XP Hay cuatro actividades básicas de desarrollo que utiliza 
la programación extrema. Dichas actividades son codificar, probar, escuchar y diseñar. El 
analista de XP necesita identificar la cantidad de esfuerzo que entrará en cada actividad y 
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el equilibrio necesario con los recursos para completar el proyecto. En la figura 6.9 se muestra 
dicho equilibrio, en la cual se describe una balanza en donde se pone una serie de pesos. En 
XP, los pesos del lado derecho son las actividades. Los pesos en el lado izquierdo son los 
recursos, que se trataron con mayor detalle en el capítulo 3. 

Codificar se designa como una actividad dado que no es posible hacer nada sin ella. 
Un autor afirma que la cosa más valiosa que recibimos de la codificación es el "aprendiza¬ 
je". El proceso básicamente es esto: tenga un pensamiento, codifíquelo, pruébelo y vea si 
ese pensamiento era lógico. También se puede codificar para comunicar ideas que de otra 
manera permanecerían borrosas o sin forma. Cuando veo su código, puedo generar un 
nuevo pensamiento. El código fuente es la base para que un sistema sobreviva. Es esencial 
para el desarrollo. 

La segunda actividad básica del desarrollo es probar. La programación extrema da mucha 
importancia a las pruebas automatizadas. La programación extrema apoya la generación de 
pruebas escritas para verificar la codificación, la funcionalidad, el rendimiento y la conformi¬ 
dad con los objetivos. XP se apoya en las pruebas automatizadas y existen grandes bibliote¬ 
cas de pruebas para la mayoría de los lenguajes de programación. Estas pruebas necesitan ser 
actualizadas conforme sea necesario durante el progreso del proyecto. 

Hay razones de corto y largo plazos para hacer pruebas. Probar a corto plazo le proporcio¬ 
na la confianza extrema en lo que está construyendo. Si las pruebas se ejecutan perfectamente 
usted puede seguir adelante con la confianza renovada. A largo plazo, probar mantiene vivo un 
sistema, y le permite hacer muchos más cambios de los que serían posibles si ninguna prueba 
fuera escrita o ejecutada. 

La tercera actividad básica del desarrollo es escuchar. En el capítulo 4 aprendimos la 
importancia de escuchar durante las entrevistas. En la programación extrema, esta actividad 
se lleva al extremo. Los desarrolladores escuchan de manera activa a sus compañeros de 
programación. En XP se depende menos de la comunicación formal escrita y por ello escu¬ 
char se vuelve una habilidad muy importante. 

El desarrollador también escucha de manera activa al cliente. Los desarrolladores asumen 
que no saben nada acerca del negocio en el que están colaborando, y por lo tanto deben escu¬ 
char cuidadosamente a los usuarios para obtener las respuestas a sus preguntas. El desarrollador 
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necesita entender la eficacia de escuchar. Si no escucha, no sabrá lo que debe codificar o lo que 
debe probar. 

La cuarta actividad básica en el desarrollo es diseñar, lo cual es una forma de crear una 
estructura para organizar toda la lógica en el sistema. Diseñar es una actividad evolutiva, y 
por ello los sistemas que se diseñan con un enfoque de la programación extrema se concep- 
tualizan como en constante evolución, siempre diseñándose. 

Con frecuencia un buen diseño es simple. También, éste debe permitir la flexibilidad: 
Diseñar bien permite agregar extensiones al sistema haciendo cambios en un solo lugar. 
El diseño eficaz ubica la lógica cerca de los datos en que estará operando. Sobre todo, el 
diseño debe ser útil para todos aquellos que lo necesitarán conforme avance el esfuerzo 
de desarrollo, incluyendo a clientes y programadores. 


Cuatro variables de control de recursos de XP Con el objetivo de lograr las actividades des¬ 
critas anteriormente, los analistas de XP necesitan-recursos. Se pueden ajustar cuatro recur¬ 
sos para completar el proyecto antes de una fecha límite: tiempo, costo, calidad y alcance. 
Cuando se incluyen adecuadamente estas cuatro variables de control en la planeación, hay 
un estado de equilibrio entre los recursos y las actividades necesarias para completar el pro¬ 
yecto. En el capítulo 3 se tratan con mayor detalle estos recursos y cómo se pueden ajustar. 


Cuatro prácticas esenciales de XP Cuatro prácticas esenciales distinguen notablemente 
a XP de otros enfoques, y por consiguiente hacen extremo a XP: liberación limitada; se¬ 
mana de trabajo de 40 horas; alojar al cliente en el sitio, y el uso de la programación en 
parejas. 

1. La liberación limitada significa que el equipo de desarrollo reduce el tiempo entre las li¬ 
beraciones de su producto. En lugar de liberar una versión completamente desarrollada 
por un año, usando la práctica de liberación limitada reducirán el tiempo de liberación 
incluyendo primero las características más importantes, liberando ese sistema o produc¬ 
to y mejorándolo después. 

2. La semana de trabajo de 40 horas significa que los equipos de desarrollo de XP apoyan 
conscientemente una práctica esencial cultural en la cual el equipo labora intensamen¬ 
te en conjunto durante una semana típica de 40 horas de trabajo. Como consecuencia 
a esta práctica, la cultura refuerza la idea de que trabajar horas extras por más de una se¬ 
mana en un turno es muy malo para la salud del proyecto y los diseñadores. Esta 
práctica esencial intenta motivar a los miembros del equipo a trabajar intensamente 
durante sus horas de trabajo, y después tomar un descanso para que cuando vuelvan 
estén relajados y menos estresados. Esto ayuda a los miembros del equipo a identifi¬ 
car los problemas más rápidamente, y previene errores costosos y omisiones debido al 
desempeño ineficaz o desgastante. 

3. El cliente en el sitio significa que un usuario experto en los aspectos de negocios del 
proyecto en desarrollo está en el sitio durante este proceso. Esta persona es fundamen¬ 
tal para el proyecto, escribe las historias del usuario, comunica a los miembros del equi¬ 
po, ayuda a priorizar y equilibrar las necesidades de largo plazo del negocio y toma de¬ 
cisiones sobre qué características se deben incluir primero. 

4. La programación en parejas es una práctica esencial importante. Significa que usted 
trabaja con otro programador de su propia elección. Ambos codifican, ambos aplican 
las pruebas. Con frecuencia, la persona con más experiencia tomará el mando de la 
codificación inicial, pero conforme se involucra la persona con menos experiencia, cual¬ 
quiera de los dos que tenga la visión más clara de la meta trabajaría en la codificación. 
Cuando le pide a otra persona que trabaje con usted, el protocolo de la programa¬ 
ción en parejas dice que está obligada a aceptar. Trabajar con otro programador le 
ayuda a aclarar su pensamiento. Las parejas cambian con frecuencia, sobre todo du¬ 
rante la fase de exploración del proceso de desarrollo. La programación en parejas 
ahorra tiempo, reduce las distracciones, activa la creatividad y es una forma diverti¬ 
da de programar. 
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Prácticas esenciales de XP 



La figura 6.10 muestra cómo se interrelacionan y dan soporte las prácticas esenciales de 
XP con las actividades, los recursos y los valores de XP, 


PROCESO Y HERRAMIENTAS DEL DESARROLLO DE XP 

Ahora que ha aprendido algo de las actividades, los recursos y las prácticas esenciales de XP, 
podemos poner en práctica dicho conocimiento. Esta sección describe el proceso de desarro¬ 
llo de la programación extrema, explica los detalles involucrados en el registro de las historias 
del usuario y examina algunas de las herramientas disponibles actualmente para desarrollar 
sistemas con un enfoque de XP. 

Proceso de desarrollo de XP En el capítulo 1 aprendió sobre el SDLC y sus diversas fases. La 
programación extrema también posee un proceso de desarrollo, pero es mucho más interacti¬ 
vo, reiterativo e integrador que el del SDLC. Sin embargo, XP no guía al desarrollador a través 
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de las fases. Más bien es incremental y con frecuencia las actividades se hacen al mismo tiem¬ 
po. Observe que diario se hacen muchos pasos del ciclo de XP. Esto contrasta claramente con 
el SDLC, mismo que procede a un paso mucho más lento y para el cual algunas actividades 
(el análisis de requerimientos, probar, etc.) deben ser completadas en fases distintas. El proce¬ 
so de XP permite lograr las actividades. 

Las cinco fases del proceso de desarrollo de XP son la exploración, planeación, iteracio¬ 
nes a la primera versión, puesta en producción y mantenimiento (véase el capítulo 3 para 
una descripción detallada de las fases). La sección siguiente describe específicamente cómo 
se despliega una sesión típica de trabajo de XP durante el proceso de desarrollo. Por ejem¬ 
plo, el proceso típico seria asumir una tarea que se relaciona directamente a una caracterís¬ 
tica del sistema que un cliente desea, probarla, implementarla en un diseño existente, e 
integrarla, todo esto durante un solo episodio del desarrollo. El día podría empezar al analizar 
el reporte de un usuario pedido en una cédula, en el cual se registra una tarea específica. 
Durante un informe, pedido para la reunión, usted hace unas preguntas sobre el trabajo hecho 
el día anterior que podría ayudar en esta tarea. Después le pide a otro programador que le 
ayude en la tarea. 

Se consulta rápidamente a otros expertos en el sitio que podrían conocer las respuestas 
a las preguntas específicas. Después se consulta el paquete existente de casos de prueba. 
Probablemente algunos se aplicarán y algunos otros se deberían escribir. 

El próximo paso sería anotar la siguiente tarea en una lista especial. Después podría escri¬ 
bir un caso de prueba para cualquier cosa que esté intentando averiguar. Finaliza y lo ejecuta. 
Probablemente fallará. Usted y su compañero miran otros casos de prueba y depuran lo que 
escribieron. Continúa con el siguiente caso de prueba, y el siguiente. Finalmente, usted llega al 
último elemento de su lista de pendientes, que seria reestructurar los otros casos de pruebas; 
y lo hace. 

Usted carga la versión actualizada y los cambios. Después aplica todos los casos de 
prueba, depura cualquiera que no se ejecute y repara el código. Cuando lo ejecuta nueva¬ 
mente y funciona, usted ha terminado. Entonces el código se puede liberar. 

Aún se podría estar preguntando cómo iniciar una tarea de desarrollo de XP. Un autor 
experimentado consigue ir directamente al corazón del problema y sólo siendo ligeramen¬ 
te gracioso, escribió: "Escoja su peor problema, resuélvalo con XP. Cuando deje de ser su 
peor problema, repita" (Wells, citado por Beck, 2000, p. 123). De esta forma, está mostran¬ 
do una gran valentía. Se está enfocando en resolver primero su problema más urgente, y 
está aplicando las estrategias de desarrollo de XP para trabajar a través del problema de 
probar, codificar, escuchar, diseñar e integrar. Está completando todas las tareas del desa¬ 
rrollo de XP en cada asignación de la programación diaria y está reconociendo que el pro¬ 
ceso de mejorar el sistema y dirigirse a los problemas graves simple y directamente son la 
clave para el éxito. 

Cómo escribir las historias de XP Aún y cuando el título de esta sección sea "Cómo es¬ 
cribir las historias de XP", el énfasis en la creación de las historias del usuario está en la 
interacción hablada entre desarrolladores y usuarios, no en la comunicación escrita. En 
las historias del usuario, el desarrollador ante todo busca identificar los requerimientos 
valiosos del usuario de negocios. Generalmente los usuarios estarán ocupados diariamen¬ 
te en las conversaciones con los desarrolladores sobre el significado de las historias del 
usuario que han escrito. Estas conversaciones frecuentes son interacciones determinadas 
que tienen como su meta la prevención de malos entendidos o malas interpretaciones de 
los requerimientos del usuario. Por lo tanto, las historias del usuario sirven como recor¬ 
datorios para los desarrolladores que deben sostener conversaciones seguras para dichos 
requerimientos. 

El siguiente es un ejemplo de una serie de historias escritas para una aplicación de comer¬ 
cio electrónico en línea para un comerciante de libros, CDs y otros productos del medio. Las 
historias dan un cuadro bastante completo de lo que se necesita en cada una de las fases en el 
proceso de compra, pero dichas historias son muy cortas y fáciles de comprender. El objetivo 
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aquí es sacar a relucir todas las necesidades e intereses de la tienda en línea. Aunque no hay 
suficientes reportes para empezar a programar, un desarrollador de XP podría empezar a ver 
bastante claro el cuadro global para empezar a estimar lo que se lleva para completar el pro¬ 
yecto. Las historias son como sigue: 

Dé la bienvenida al cliente. 

Si el cliente ha estado en este sitio antes usando esta misma computadora, déle la bienveni¬ 
da de nuevo a la tienda en línea. 

Muestre los aspectos especiales en la página de inicio. 

Muestre cualquier libro nuevo u otros productos que se han introducido recientemente. Si se 
identifica al cliente, ajuste las recomendaciones al gusto de ese cliente en particular. 

Busque el producto deseado. 

Incluya un mecanismo de búsqueda eficaz que localizará el producto específicoy losproduc- 
tossimilares. 

Muestre los títulos correspondientes y la disponibilidad. 

Despliegue los resultados de la búsqueda en una nueva página Web. 

Permítale al cliente pedir mayor detalle. 

Ofrezca al cliente más detalles del producto, tales como páginas de muestra en un libro, más 
fotografías de un producto o tocar parte de una pista de un CD. 

Presente las opiniones del producto. 

Comparta los comentarios que otros clientes tienen sobre el producto. 

Ponga un producto en un carrito de compras. 

Hágalofácil para el cliente. Que sólo haga clic en un botón que ponga el producto en un ca¬ 
rrito de las compras deseadas. 

Registre el historial de la compra en un archivo. 

Guarde los detalles del cliente y sus compras en una cookie en la computadora del cliente. 
También guarde la información de la tarjeta de crédito para una verificación rápida. 

Sugiera otros libros similares. 

Incluya foto grafías de otros libros que tienen temas similares o fueron escritos por los mis- 
mosautores. 

Proceda a la verificación. 

Confirme la identidad del cliente. 

Revise las compras. 

Permítale al cliente revisarlas compras. 

Continúe la compra. 

Déle la oportunidad al cliente de hacer compras adicionales al mismo tiempo. 

Aplique métodos abreviados para una verificación más rápida. 

Si se conoce la identidad del clientey ¡a dirección de entrega corresponde, se acelera la tran¬ 
sacción aceptando la tarjeta de crédito en el archivo y el resto de las preferencias del cliente, 
tales como el método de envío. 

Agregue los nombres y las direcciones de envío. 

Si la compra es un regalo, el cliente puede agregar el nombrey dirección del destinatario. 
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Como puede ver fácilmente, no hay escasez de historias. El analista de XP necesita 
escoger unas historias, completar la programación y liberar un producto. Una vez que esto 
se hace, se seleccionan más historias y se libera una nueva versión hasta que se incluyan 
todas las historias en el sistema (o el analista y cliente estén de acuerdo que a una historia 
particular le falta mérito, o no es urgente, y por ello no es necesario incluirla). 

En la figura 6.11 se muestra el ejemplo de una historia de usuario como podría aparecerle 
a un desarrollador de XP. En las cédulas (o electrónicamente), un analista podría identificar 
primero la necesidad u oportunidad, y seguir con una descripción breve de la historia. El ana¬ 
lista podría aprovechar la oportunidad de iniciar pensando ampliamente sobre las actividades 
que necesitan ser completadas así como también los recursos que tomará para terminar el 
proyecto. En este ejemplo del comerciante en línea, el analista indica que diseñar la actividad 
tomará un esfuerzo superior, y que se requieren los recursos de tiempo y calidad superiores al 
promedio. Observe que el analista no está intentando ser más preciso de lo que actualmente 
es posible en esta estimación, pero aún es un ejercicio útil. 


Herramientas de desarrollo de XP Hay varias herramientas preferidas por los desarrollado¬ 
res de XP. Los creadores originales del enfoque de XP trabajaban en SmallTalk, y con el 
tiempo trasladaron su marco de pruebas unitarias (SUnit) a Java, el cual actualmente se lla¬ 
ma JUnit. Hay muchos recursos en Web que le permiten descargar los marcos de prueba 
xUnit para cualquier lenguaje de desarrollo de software que esté usando. 

Los creadores de XP tuvieron cuidado de no mezclar sus principios de XP con herra¬ 
mientas de desarrollo particulares. Esto significa que XP puede ser tan flexible como sea 
necesario todo el tiempo, y también puede evolucionar con nuevas herramientas que estén 
disponibles. Las herramientas vienen y van, pero los principios deben permanecer intactos 
sin tener en cuenta esa variabilidad. 

Muchas de las herramientas usadas en el desarrollo de XP son baratas o completa¬ 
mente gratuitas. Hay un sitio Web excelente, SourceForge.net, en el que se puede encon¬ 
trar la mayoría de las herramientas de desarrollo de software. Como verá al examinar el 
sitio, la programación extrema se usa en muchos lenguajes y plataformas de software, pero 
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los dos líderes indiscutibles en lo que se refiere al uso extendido y popularidad son Java 
y Microsoft .NET. 

Hay muchos tipos diferentes de herramientas disponibles que dan soporte a las activi¬ 
dades que necesitaría realizar al hacer el desarrollo de XP. Se incluyen herramientas que 
facilitan la colaboración tales como Wilci Wiki, Whiteboard, Project Web, NetMeeting e 
IBM's Rational ProjectConsole. También hay herramientas tales como IBM's Pational 
ClearCase, Visual Intercept, Compuware Track Record y Bliplt que dan soporte a la admi¬ 
nistración de defectos. 

Los probadores unitarios automatizados, probadores de aceptación y probadores de 
GUI incluyen JUnit, ComUnit, VBUnit, Nunit, httpUnit y Rational Visual Test Tools. Dev- 
Partner Code Review ayuda con el control de calidad. Además hay herramientas que ayudan 
con la medición del sistema y desempeño de componentes tales como Jmeter, JUnitPerf, 
PerfMon, TrueTime, RealTime y Microsoft Visual Studio Analyzer. También hay herramientas 
que ayudan con la administración de la configuración del código fuente, incluyendo CVS, 
Visual Source Safe y PVCS. Por último, hay una clase de herramientas con la cual probable¬ 
mente ya está familiarizado, los entornos de desarrollo de IBM VisualAge, Microsoft Visual 
Studio .NET y JBuilder. 

LECCIONES APRENDIDAS DE XP 

Varios proyectos de programación extrema se han descrito en libros, artículos y sitios Web. 
Muchos de ellos han sido exitosos, algunos han fracasado, pero al estudiarlos podemos 
aprender mucho de ellos, así como también de los valores, principios y prácticas esenciales de 
XP. A continuación se presentan las seis lecciones más importantes que obtuvimos al exa¬ 
minar XP. En la figura 6.12 se muestra un diagrama de esas seis lecciones. 

La primera lección es que la liberación limitada permite que evolucionen los sistemas. 
Con frecuencia se hacen actualizaciones al producto, y los cambios se incorporan rápidamen¬ 
te. De esta forma se permite al sistema crecer y extenderse para que el cliente lo encuentre 
útil. Al utilizar la liberación limitada, el equipo de desarrollo reduce el tiempo entre las ver¬ 
siones de su producto, mejorando el producto posteriormente conforme lo exija la situación 
dinámica. 
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La segunda lección es que la programación en parejas incrementa la calidad global. Aun¬ 
que la programación en parejas es polémica, fomenta claramente otras actividades positivas 
necesarias en el desarrollo de sistemas tales como una comunicación buena, identificarse con 
el cliente, enfocarse primero en los aspectos más valiosos del proyecto, probar todo el códi¬ 
go tal como se desarrolla e integrar el nuevo código después de que sus fases se prueban con 
éxito. 

La tercera lección es que los clientes en el sitio son benéficos tanto para el negocio 
como para el equipo de XP. Los clientes sirven como una referencia rápida y un control 
real, y el enfoque del diseño de sistemas siempre se mantendrá en su presencia: los clien¬ 
tes se parecen más a los desarrolladores y los desarrolladores sienten más empatia con los 
clientes. 

La cuarta lección que tomamos de XP es que la semana de trabajo de 40 horas mejora 
la eficiencia. Incluso los mejores desarrolladores son susceptibles a cometer errores y se des¬ 
gastan si trabajan demasiado duro durante un periodo prolongado. Sin embargo, cuando el 
equipo de desarrollo está junto cada momento cuenta. [Trabajar a un ritmo sostenible es 
mucho más provechoso para la vida del proyecto, la vida del sistema y la vida del desarro- 
lladorl Todos conocemos la moraleja de la liebre y la tortuga. 

La quinta lección que deducimos de XP es que los recursos y actividades equilibrados 
dan soporte a los objetivos del proyecto. Administrar un proyecto no sólo significa obtener 
en conjunto todos los recursos y tareas. También significa que el analista se enfrenta a varios 
pros y contras. Algunas veces el costo podría estar predeterminado, en otro momento de cri¬ 
sis, el tiempo podría ser el factor más importante. Las variables de control de recursos de 
tiempo, costo, calidad y alcance necesitan equilibrarse adecuadamente con las actividades 
de codificar, diseñar, probar y escuchar. 

La última lección que tomamos de la programación extrema es que los valores de XP 
son importantes para su éxito. Es fundamental para el éxito del proyecto que los analistas 
incluyan incondicionalmente los valores de comunicación, sencillez, retroalimentación y 
valentía en todo el trabajo que hagan. Este tipo de compromiso personal y en equipo per¬ 
mite al analista tener éxito en situaciones donde, quien posee capacidades técnicas similares 
pero carece de valores, fallaría. Una verdadera dedicación a estos valores es fundamental para 
que el desarrollo sea exitoso. 

MODELADO ÁGIL Y MELÉ (SCRUM) 

El modelado ágil se basa en los valores, al igual que la programación extrema. Además de 
los valores de comunicación, sencillez, retroalimentación y valentía, se ha agregado un quinto 
valor: la humildad. Se requiere una corta lección de la historia. En los primeros 25 años de 
la computación, el software de la computadora fue desarrollado por expertos que con fre¬ 
cuencia creían saber cómo funcionaba un negocio mejor que los expertos del dominio, sus 
clientes. Con frecuencia fueron llamados los "gurús" de la computadora. Estos gurús eran 
muy egocentristas e insistieron en que siempre tenían la razón, aun cuando el cliente pensó 
de forma distinta. Los gurús no tenían la virtud de ser humildes. 

Sin embargo, el valor de la humildad es crítico. Los modeladores ágiles son analistas de 
sistemas que hacen sugerencias, expresan opiniones, pero no insisten en que siempre tienen 
la razón. Están seguros de sí mismos para permitirles a sus clientes cuestionar, criticar y algu¬ 
nas veces quejarse del sistema que están desarrollando. Reconocen que pueden aprender de 
sus clientes. Después de todo, los clientes son los que han tenido la experiencia de operar el 
negocio durante un periodo largo. También los clientes son responsables del resultado final. 
Existen mientras la compañía tiene buenas épocas. Los consultores van y vienen, pueden 
cambiar mucho. 

El modelado ágil también abarca un conjunto de principios esenciales. Además de 
los principios esenciales de la programación extrema, el modelado ágil agrega principios 
tales como "modelar con un propósito", "el software es su meta principal" y "viajar con 
poco equipaje", una forma de decir que poca documentación es suficiente. 
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El modelado es una palabra clave en los métodos ágiles. A diferencia de XP, el modelado 
ágil aprovecha la oportunidad de crear modelos. Éstos pueden ser modelos lógicos tales 
como diseños de sistemas, o modelos como prototipos descritos anteriormente en este capítulo. 
Un proceso típico de modelado ágil podría ser algo como lo siguiente: 

1. Escuche las historias de usuario del cliente (parecidas a las historias de usuario de XP). 

2. Dibuje un modelo de flujo de trabajo lógico para tener una perspectiva de las decisiones 
del negocio representadas en la historia del usuario. 

3. Cree nuevas historias del usuario basadas en el modelo lógico. 

4. Desarrolle algunos prototipos de muestra. Con ello, muestre al cliente qué clase de 
interfaz tendrá. 

5. Usando la retro aumentación de los prototipos y los diagramas de flujo de trabajo lógicos, 
desarrolle el sistema hasta que cree un modelo de datos físico. 

Ágil es la otra palabra clave en el modelado ágil. Ágil significa maniobrabilidad. Los sis¬ 
temas actuales, sobre todo aquellos que se basan en Web, representan una doble demanda: 
liberar el software tan pronto como sea posible y mejorarlo continuamente para agregar 
nuevas características. El analista de sistemas debe tener la habilidad y métodos para crear 
las aplicaciones dinámicas, contextúales, escalables y evolutivas. El modelado ágil tal como 
un método de aceptación de cambios, no es diferente a la programación extrema. 

Un enfoque ágil se conoce como "melé". La palabra melé se toma de la posición de 
arranque en rugby en la cual los equipos se ponen frente a frente y pelean por la posesión 
del balón. En realidad melé se refiere al trabajo en equipo, similar a lo que se necesita hacer 
en un juego de rugby. 

Tal como los equipos de rugby empezarán un juego con una estrategia global, los equi¬ 
pos de desarrollo empiezan el proyecto con un plan de alto nivel que puede cambiarse sobre 
la marcha conforme avance el "juego". Los miembros del equipo de desarrollo de sistemas 
comprenden que el éxito del proyecto es más importante, y su éxito individual es secunda¬ 
rio. El líder del proyecto tiene alguna, pero no mucha, influencia en los detalles. Más bien, las 
tácticas del juego se dejan a los miembros del equipo, como si estuvieran en el campo. El 
equipo de sistemas trabaja dentro de un horario estricto (30 días para el desarrollo), así co¬ 
mo un equipo de rugby jugaría limitándose estrictamente al tiempo de un juego. 

Podemos describir los componentes de la metodología de melé como: 

1. Productos atrasados, en donde se deriva una lista de las especificaciones del producto. 

2. Atrasos para arrancones, una lista cambiante dinámicamente de tareas a ser completadas 
en el próximo arrancón. 

3. Arrancón, un periodo de 30 días en el cual el equipo de desarrollo transforma el atraso, 
en software que puede demostrarse. 

4. Melé diaria, una reunión breve donde la comunicación es la regla número uno. Los 
miembros del equipo necesitan explicar lo que hicieron desde la última reunión, si en¬ 
contraron obstáculos y qué planean hacer antes de la próxima melé diaria. 

5. Software funcional de demostración que puede demostrarse al cliente. 

De hecho, melé es una metodología de alta intensidad. Es sólo uno de los enfoques que 
adoptan la filosofía del modelado ágil. 



RESUMEN 

La elaboración de prototipos es una técnica útil de recopilación de información para com¬ 
plementar el ciclo de vida del desarrollo tradicional de sistemas. Cuando los analistas de sis¬ 
temas usan la elaboración de prototipos, están buscando las reacciones del usuario, sugeren¬ 
cias, innovaciones y la revisión planeada para mejorar el prototipo, y por consiguiente 
modificar los planes del sistema con un gasto e interrupción mínimos. Los sistemas que 
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apoyan la toma de decisiones semiestructurada [como lo hacen los sistemas de apoyo a la 
decisión) son los primeros candidatos para la elaboración de prototipos. 

El término elaboración de prototipos acepta varios significados diferentes, de los cuales 
cuatro se usan comúnmente. La primera definición de la elaboración de prototipos es la de 
construir un prototipo como un sistema corregido. Una segunda definición es la de un proto¬ 
tipo no funcional que se usa para probar ciertos aspectos del diseño. Como tercera definición 
está la de crear el primer prototipo de una serie que es totalmente funcional. Esta clase de 
prototipo es útil cuando se planean muchas instalaciones del mismo sistema de información 
(bajo condiciones similares]. La cuarta clase de la elaboración de prototipos es un prototipo 
con características seleccionadas que tiene algunas, pero no todas, las características principa¬ 
les del sistema. Usa módulos independientes como los blocks para construcción de manera 
que si las características del prototipo elaborado son exitosas, se puedan mantener e incorpo¬ 
rarse en el sistema final. 

Los cuatro lincamientos principales para desarrollar un prototipo son: (1) trabajar en 
módulos manejables; (2} construir rápidamente el prototipo; (3) modificar el prototipo, y 
(4) poner énfasis en la interfaz de usuario. 

Una desventaja de los prototipos es que administrar el proceso de la elaboración de 
prototipos es difícil debido a la rapidez del proceso y a sus muchas iteraciones. Una segun¬ 
da desventaja es que un prototipo incompleto podría ser forzado a colocarse en servicio como 
si fuera un sistema completo. 

Aunque la elaboración de prototipos no siempre es necesaria o deseable, se debe obser¬ 
var que hay tres ventajas principales relacionadas con su uso: (1) la aptitud para cambiar a 
tiempo el sistema en su desarrollo, (2) la oportunidad de detener el desarrollo de un siste¬ 
ma que no está funcionando y (3} la posibilidad de desarrollar un sistema que se ajuste más 
estrechamente a las necesidades y expectativas de los usuarios. 

Los usuarios tienen que desempeñar un papel diferente en el proceso de la elaboración 
de prototipos. Su ocupación principal debe ser interactuar con el prototipo a través de la 
experimentación. Los analistas de sistemas deben trabajar sistemáticamente para identificar 
y evaluar las reacciones de los usuarios al prototipo. 

Un uso particular de la elaboración de prototipos es el de desarrollo rápido de aplica¬ 
ciones, o RAD. Este es un enfoque orientado a objetos con tres fases: planeación de reque¬ 
rimientos, taller de diseño del RAD e implementación. 

La programación extrema (XP) es un enfoque de desarrollo de software que toma lo 
que generalmente designamos como buenas prácticas de desarrollo de software y las lleva al 
extremo. XP define con rapidez un plan global, desarrolla, libera rápidamente el software y 
después lo revisa de manera continua para agregarle características adicionales. Los progra¬ 
madores de XP trabajan en parejas para desarrollar sistemas de calidad. 

Los cuatro valores de XP que son compartidos por el cliente comercial así como tam¬ 
bién por el equipo de desarrollo son comunicación, sencillez, retroalimentación y valentía. 
Los cinco principios básicos de XP consisten en proporcionar una retroalimentación rápi¬ 
da; adoptar la simpleza al abordar una nueva tarea de programación; cambiar el código, el 
diseño, e incluso al equipo de desarrollo, de manera gradual; aceptar el cambio como un es¬ 
tado normal del trabajo, y hacer un trabajo de calidad. Las actividades de XP incluyen co¬ 
dificar, probar, escuchar y diseñar. Los recursos disponibles incluyen tiempo, costo, calidad 
y alcance. 

Las cuatro prácticas esenciales de XP son: (1) liberación limitada; [2) semana de trabajo 
de 40 horas; (3) cliente en el sitio, y (4) programación en parejas. Dichas prácticas distin¬ 
guen a la programación extrema de otros procesos de desarrollo de sistemas. Las cinco fases 
amplias en el proceso de desarrollo de XP son la exploración, planeación, las iteraciones a la 
primera versión, puesta en producción y mantenimiento. 

El proceso de desarrollo de XP incluye seleccionar una tarea que se relaciona directa¬ 
mente a una característica deseada por el cliente que se basa en las historias del usuario; 
escoger a un compañero de programación; seleccionar y escribir los casos de prueba adecua¬ 
dos; escribir el código; aplicar los casos de prueba; depurar el código hasta que se apliquen 
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"Gracias a Dios ésta es la época del año en que todo es nuevo. Yo amo la primavera; es la 
época más excitante aquí en MRE. Los árboles son tan verdes, con hojas de diversas tona¬ 
lidades. Tantos nuevos proyectos por hacer, también; tantos nuevos clientes por conocer. 
Es realmente excitante. Me recuerda la elaboración de prototipos. O lo que sé sobre la 
elaboración de prototipos. Es algo nuevo y fresco, una manera rápida de averiguar lo que es¬ 
tá pasando." 

"De hecho, creo que ya tenemos algunos prototipos por aqüí. Lo mejor de todo es que 
pueden cambiar. No conozco a nadie que realmente haya quedado satisfecho con un primer 
prototipo. Pero es divertido involucrarse con algo que sé hace rápidamente, y que cambiará." 



Lili 


PREGUNTAS DE HYPERCASE 

1. Localice algún prototipo propuesto que se use actualménte en uno de lós departamentos 
de MRE. Sugiera algunas modificaciones que harían este prototipo aún más sensible a 
las necesidades de la unidad. 

2. Usando un procesador de texto, construya un prototipo no funcional para un Sistema 
de Informes sobre Proyectos para la Unidad de Capacitación. Si dispone de un progra¬ 
ma de hipertexto, intente incorporar alguna funcionalidad agregando menús con opciones 
que se puedan seleccionar. Sugerencia: tome como base para su diseño las pantallas de 
ejemplo de los capítulos 11 y 12. 


Sistema global de ingeniería de administración 


Recursos de edidón 


Numera recurso |l 


Nombre ddrecurso ¡Taylor 


Ubicación del reamo JMSU14 
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Disponibilidad del recurso JBar hora ¡_ A J 
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Número de pedida jl | 
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Uñá.dejaé muchas^^ pantallas dé: protptipo que se encuentran en HyperCase. 






todos los casos de prueba; implementarlo con el diseño existente, e integrarlo a lo que ac¬ 
tualmente existe. 

Hay seis lecciones que aprender del enfoque de XP. La primera lección es que las libe¬ 
raciones en corto permiten evolucionar a los sistemas. La segunda lección es que la progra¬ 
mación en parejas refuerza la calidad global. La tercera lección es que los clientes en el sitio 
y el equipo de XP se benefician mutuamente. La cuarta lección es que la semana de traba¬ 
jo de 40 horas mejora la eficiencia. La quinta lección es que los recursos y actividades equi¬ 
librados apoyan las metas del proyecto. La última lección que tomamos de la programación 
extrema es que los valores de XP son fundamentales para el éxito. 

El modelado ágil abarca un conjunto de principios básicos. Un valor que los modelado¬ 
res ágiles poseen es la humildad. Además de los principios esenciales de la programación ex¬ 
trema, el modelado ágil agrega principios tales como "modelar con un propósito", "el soft¬ 
ware es su meta principal" y "viajar con poco equipaje", una forma de decir que poca 
documentación es suficiente. Una forma de implementar el modelado ágil es con la meto¬ 
dología de melé. 

PALABRAS Y FRASES CLAVE 


aceptar el cambio 
adoptar la sencillez 
cambio ¡ncremental 
cliente en el sitio 

desarrollo rápido de aplicaciones (RAD) 
énfasis en la interfaz de usuario 
fase de exploración 
fase de mantenimiento 
fase de planeación 

fase de planeación de requerimientos 
fase de puesta en producción 
historias del usuario 
implementación 

intervención del usuario en la elaboración 
de prototipos 

iteraciones a la primera fase de liberación 
liberación limitada 


metodología melé 
modelado ágil 
modificar el prototipo 
primer prototipo de una serie 
principios de XP 
programación en parejas 
programación extrema (XP) 
prototipo 

prototipo corregido 
prototipo de características 
seleccionadas 
prototipo no funcional 
retroalimentación rápida 
semana de trabajo de 40 horas 
taller de diseño del RAD 
trabajar en módulos manejables 
valores de XP 



PREGUNTAS DE REPASO 

1. ¿Cuáles son los cuatro tipos de información que busca el analista en la elaboración de 
prototipos? 

2. ¿Qué significa el término prototipo corregido! 

3. Defina un prototipo que es un modelo a escala no funcional. 

4. Proporcione un ejemplo de un prototipo que es un primer modelo a escala completa. 

5. Defina lo que significa un prototipo que es un modelo con algunas, pero no todas, las 
características principales. 

6. Haga una lista de las ventajas y desventajas de usar la elaboración de prototipos para 
reemplazar el ciclo de vida del desarrollo tradicional de sistemas. 

7. Describa cómo se puede usar la elaboración de prototipos para aumentar el ciclo de vida 
del desarrollo tradicional de sistemas. 

8. ¿Cuáles son los criterios para decidir si se debe hacer un prototipo de un sistema? 

9. Mencione cuatro lincamientos que el analista debe observar en el desarrollo de un 
prototipo. 

10. ¿Cuáles son los dos problemas principales identificados en la elaboración de prototipos? 

11. Mencione las tres ventajas principales de utilizar la elaboración de prototipos. 

12. ¿Cómo puede un prototipo de un sitio Web interactivo facilitar el proceso de la elabora¬ 
ción de prototipos? Conteste en un párrafo. 
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13. ¿Cuáles son las tres formas en que un usuario puede ser de ayuda en el proceso de la 
elaboración de prototipos? 

14. Defina lo que significa RAD. 

15. ¿Cuáles son las tres fases del RAD? 

16. Defina la programación extrema. 

17. ¿Cuáles son los cuatro valores que deben compartir el equipo de desarrollo y los clientes 
de negocios cuando se toma un enfoque de programación extrema? 

18. ¿Cuáles son los cinco principios básicos de la programación extrema? 

19. ¿Cuáles son las cuatro prácticas principales del enfoque de desarrollo de XP? 

20. Delinee los pasos típicos en un episodio de desarrollo de XP. 

21. ¿Qué es una historia de usuario? ¿Es principalmente escrita o hablada? Elija su opción, 
luego apoye su respuesta con un ejemplo. 

22. Mencione las herramientas de software que pueden ayudar al desarrollador a hacer una 
variedad de pruebas de código. 

23. ¿Cuáles son las seis lecciones tomadas de la experiencia con los esfuerzos del desarrollo 
deXP? 

24. Compare y contraste el modelado ágil con el enfoque de XP. 

25. ¿Qué es melé? 

PROBLEMAS 

1. Como parte de un proyecto de sistemas extenso. Clone Bank de Clone, Colorado, ne¬ 
cesita su ayuda para crear un nuevo formulario de informe mensual para las cuentas 
de cheques y ahorros de sus clientes. El presidente y el vicepresidente están en sintonía 
con lo que dicen los clientes en la comunidad. Piensan que sus clientes quieren un re¬ 
sumen de la cuenta de cheques que se parezca al que ofrecen los otros tres bancos de la 
ciudad. Sin embargo, no están dispuestos a hacer ese formulario sin un resumen formal 
de retroalimentación del cliente que apoye sus decisiones. La retro alimentación no se 
usará para cambiar el formulario del prototipo de ninguna forma. Ellos quieren que us¬ 
ted envíe el prototipo de un formulario a un grupo y el formulario viejo a otro grupo. 

a. En un párrafo explique por qué probablemente no es importante crear un prototi¬ 
po de sistema para el nuevo formulario bajo estas circunstancias. 

b. En un segundo párrafo explique bajo qué situación seria aconsejable crear un pro¬ 
totipo para el nuevo formulario. 

2. Por muchos años C. N. Itall ha sido analista de sistemas para la Tun-L-Vision Corpora¬ 
tion. Cuando usted se integró al equipo de análisis de sistemas y sugirió la elaboración 
de prototipos como parte del SDLC para un proyecto actual, C. N. dijo: "Seguro, pero 
no puede prestar atención a lo que dicen los usuarios. No tienen idea de lo que quieren. 
Elaboraré el prototipo, pero no 'observaré' a ningún usuario". 

a. Tan cuidadosamente como sea posible, de manera que no moleste a C. N. Itall, haga 
una lista de las razones que apoyan la importancia de observar las reacciones, suge¬ 
rencias e innovaciones del usuario en el proceso de la elaboración de prototipos. 

b. En un párrafo describa lo que podría pasar con los sistemas siguientes si se desa¬ 
rrollara parte de un sistema y no se incorporara ninguna retroalimentación del 
usuario. 

3. "Cada vez que pienso que he capturado los requerimientos de información del usuario, 
éstos ya han cambiado. Es lo mismo que intentar pegarle a un blanco en movimiento. La 
mitad del tiempo, creo que ellos mismos aún no saben lo que quieren", exclama Fio 
Chart, analista de sistemas para 2 Good 2 Be True, una empresa que inspecciona el pro¬ 
ducto utilizado para las divisiones de marketing de varias compañías industriales. 

a. En un párrafo, explique a Fio Chart cómo la puede ayudar la elaboración de proto¬ 
tipos a definir bien los requerimientos de información de los usuarios. 

b. En un párrafo, comente sobre la observación de Fio: "La mitad del tiempo, creo que 
ellos mismos aún no saben lo que quieren". Asegúrese de explicar cómo puede 
ayudar realmente la elaboración de prototipos a los usuarios a entender y articular 
mejor sus propios requerimientos de información. 
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c. En un párrafo, sugiera cómo un sitio Web interactivo que presente un prototipo 
podría resolver las preocupaciones de Fio sobre la captura de los requerimientos de 
información del usuario. 

4. Harold, un gerente de departamento de la cadena de tiendas Sprocket's Gifts, piensa 
que la construcción de un prototipo puede significar sólo una cosa: un modelo a escala 
no funcional. También cree que esta forma es demasiado incómoda para hacer prototipos 
de los sistemas de información y por ello es renuente a hacerlo. 

a. Brevemente (en dos o tres párrafos) compare y contraste los otros tres tipos de ela¬ 
boración de prototipos que son posibles para que Harold comprenda lo que puede 
significar la elaboración de prototipos. 

b. Harold tiene la opción de implementar un sistema, probarlo y después instalarlo 
en otras cinco ubicaciones de Sprocket, si tiene éxito. Nombre un tipo de elabora¬ 
ción de prototipos que encajaría bien con este enfoque, y en un párrafo respalde su 
opción. 

5. "[He tenido la idea del siglo!", clama Bea Kwicke, nuevo analista de sistemas de su grupo 
de sistemas. "Saltémonos toda esta basura del SDLC y tan sólo hagamos un prototipo de 
todo. Nuestros proyectos irán mucho más rápido, nos ahorraremos tiempo y dinero, y to¬ 
dos los usuarios sentirán como si les pusiéramos atención en lugar de alejamos sucesiva¬ 
mente durante meses y no hablar con ellos." 

a. Liste las razones que usted (como miembro del mismo equipo que Bea} le daría pa¬ 
ra disuadirla de intentar desechar el SDLC y hacer un prototipo de cada proyecto. 

b. Bea no está muy de acuerdo con lo que ha dicho. Para animarla, use un párrafo 
para explicar las situaciones que piensa se presentarían en la elaboración de pro¬ 
totipos. 

6. El comentario siguiente se oyó por casualidad en una reunión entre los gerentes y un 
equipo de análisis de sistemas en la compañía Fence-Me-In: "Usted nos dijo que el pro¬ 
totipo estaría listo hace tres semanas. [Aún lo estamos esperando!" 

a. En un párrafo, comente la importancia de entregar rápidamente una parte de un 
prototipo elaborado de un sistema de información. 

b. Mencione tres elementos del proceso de la elaboración de prototipos que se deben 
controlar para asegurar la entrega puntual del prototipo. 

c. ¿Cuáles son algunos de los elementos del proceso de la elaboración de prototipos 
que son difíciles de manejar? Lístelos. 

7. Examine la recopilación de historias de usuario del comerciante en línea mostrado an¬ 
teriormente en el capítulo. A la tienda de medios en línea ahora le gustaría que usted 
agregue algunas características a su sitio Web. Siguiendo el formato mostrado en la figu¬ 
ra 6.11 escriba una historia de usuario para las características listadas debajo: 

a. Incluya anuncios desplegables. 

b. Ofrezca compartir los detalles de las compras del cliente con sus amigos. 

c. Extienda la oferta para permitir comprar otros artículos. 

8. Visite el sitio Web de las herramientas Palm en www.palmgear.com. Explore el sitio 
Web y haga un reporte de una docena de historias de usuario breves para mejorar el 
sitio Web. 

9. Visite el sitio Web de techtv en www.techtv.com y-haga un reporte de una docena de 
historias de usuario breves para mejorar el sitio Web. 

10. Usando las historias que escribió en el problema 7, pase por las cinco fases del proceso 
de desarrollo de XP y describa lo que sucede en cada una de ellas. 

PROYECTOS DE GRUPO 

1. Divida su grupo en dos subgrupos más pequeños. Haga que el grupo 1 siga los procesos 
especificados en este capítulo para crear prototipos. Usando una herramienta CASE o 
un procesador de texto, el grupo 1 debe diseñar dos pantallas de prototipo no funcio¬ 
nales usando la información recopilada en las entrevistas con empleados de Maverick 
Transport completados en el ejercicio de grupo del capítulo 4. Haga las suposiciones 
necesarias para crear dos pantallas para despachadores de camiones. El grupo 2 (repre- 
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sentando los papeles de despachadores) deben reaccionar a las pantallas de prototipo y 
proporcionar retro alimentación sobre las adiciones y eliminaciones deseadas. 

2. Los miembros del grupo 1 deben revisar las pantallas de prototipo basados en los comen¬ 
tarios del usuario que hayan recibido. Los del grupo 2 deben responder con comentarios 
acerca de qué tan bien se resolvieron sus preocupaciones iniciales en los prototipos 
refinados. 

3. En grupo, expliquen en un párrafo sus experiencias con la elaboración de prototipos 
para determinar los requerimientos de información. 
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ALLEN SCHMIDT, JULIE E. KENDALL Y KENNETH E. KENDALL 


ES HORA DE REACCIONAR 


"Necesitamos saber lo que quieren los usuarios respecto a la salida", comenta Anna. "Esto 
nos ayudará a confirmar algunas de nuestras ideas sobre la información que necesitan." 

"Estoy de acuerdo", contesta Chip. "También nos ayudará a determinar la entrada nece¬ 
saria. A partir de ahí podemos diseñar las pantallas de entrada de datos correspondientes. 
Generemos prototipos de los informes y las pantallas y obtengamos retroalimentación de 
los usuarios. ¿Por qué no usamos Microsoft Access para crear rápidamente pantallas e infor¬ 
mes? Conozco bien el software." 

Anna empieza por desarrollar el prototipo del informe PREVENTIVE MAINTENAN- 
CE REPORT. Basada en los resultados de las entrevistas, comienza a generar el informe que 
cree que necesitará Mike Crowe. 

"Este informe se debe usar para predecir cuándo se les debe dar mantenimiento pre¬ 
ventivo a las máquinas", piensa Anna. "Me parece que Mike necesita saber qué máquina 
tiene que realizar el trabajo, así como también cuándo se debe programar el trabajo. Ahora 
veamos, ¿qué información identificaría claramente la máquina? El número de inventario, la 
marca y el modelo identificarían la máquina. Pienso que la sala y el campus se deben incluir 
para localizar rápidamente la máquina. Una fecha de mantenimiento calculada le indicaría 
a Mike cuándo se debe completar el trabajo. ¿En qué secuencia debe estar el informe? Tal 
vez la más útil seria por ubicación." 

En la figura E6.1 se muestra el prototipo del informe PREVENTIVE MAINTENAN- 
CE REPORT que presenta el informe terminado. Observe que Xxxxxxx y las fechas gené¬ 
ricas se usan para indicar en dónde se deben imprimir los datos. Se incluyen las ubicaciones 
reales del campus y la sala así como también los números de inventario. Estos son necesarios 
para que Microsoft Access realice la impresión del grupo. 

El prototipo del informe se termina rápido. Después de imprimir la última copia, Anna 
lleva el informe a Mike Crowe y Dot Matricks. Mike Crowe está entusiasmado con el proyecto 
y quiere saber cuándo estará en producción el informe. Dot también está impresionada. 

Surgen varios cambios. Mike quiere un área para escribir la fecha límite del manteni¬ 
miento preventivo de manera que el informe se pueda usar para reingresar las fechas en la 
computadora. Dot quiere que el número de informe asignado por el control de datos 
aparezca en la parte superior del formulario con el fin de que sirva de referencia. También 
sugiere que el título del informe se cambie a WEEKLY PREVENTIVE MAINTENANCE 
REPORT. Los próximos pasos son modificar el prototipo del informe para reflejar los cam¬ 
bios recomendados y después dárselo a Mike y Dot para que revisen el resultado. 

El informe se modifica e imprime fácilmente. Dot está contenta con el resultado final. 
"En realidad éste es un buen método para diseñar el sistema", comenta. "Es muy agradable 
sentir que somos parte del proceso de desarrollo y que nuestras opiniones cuentan. Estoy 
empezando a sentir bastante confianza de que el sistema final será lo que siempre hemos 
querido." 

Mike expresa un cumplido similar: "Esto hará mucho más fluido nuestro trabajo. Elimi¬ 
na la necesidad de adivinar qué máquinas requieren mantenimiento. Y ordenarlas por sala 
es una buena idea. No tendremos que invertir tanto tiempo en regresar a las salas para tra¬ 
bajar en las máquinas". 

Chip toma nota de cada una de estas modificaciones en un Formulario de Evaluación 
de Prototipo. Este formulario ayuda a Chip a organizarse y documentar el proceso de la ela¬ 
boración de prototipos. (En la figura 6.3 se muestra un ejemplo de este formulario.) 
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FIGURA 


Prototipo del informe PREVENTIVE MAINTENANCE REPORT. Este informe debe modificarse. 


A continuación. Chip y Anna centran su atención en crear los prototipos de pantalla. 
"Como a mí me gusta el aspecto del hardware del sistema, ¿por qué no empiezo a trabajar 
en el diseño de la pantalla ADD NEW COMPUTER?", pregunta Chip. 

"Me parece bien", contesta Anna. "Me enfocaré en los aspectos del software." 

Chip analiza con Dot y Mike los resultados de las entrevistas detalladas. Recopila una 
lista de los elementos que cada usuario necesitaría al agregar una computadora. Otros ele¬ 
mentos, tales como la información de ubicación y mantenimiento, actualizarían poste¬ 
riormente el archivo COMPUTER MASTER, después de instalar la máquina. 

En la figura E6.2 se muestra el prototipo de la pantalla ADD NEW COMPUTER que 
se creó con la característica de formularios de Access. En la parte superior de la pantalla es¬ 
tán la fecha y la hora actuales así como el título de la pantalla centrado. Los títulos de los 
campos se colocan alineados a la izquierda en la pantalla. Se incluyen casillas de verificación 
para varios campos, así como listas desplegables para el tipo de monitor, impresora y cone- 
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Prototipo de la pantalla ADD NEW COMPUTER. Microsoft Access se utilizó como herramienta 
para elaborar los prototipos. Las mejoras se pueden hacer en esta etapa. 
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xiones de red. Se incluye una pequeña tabla de' códigos de tarjeta (Board Code) para agre¬ 
gar varias tarjetas internas a una computadora. Se incluyen los botones "Add Record" y 
"Print". 

"El hecho de tener definidas las tablas de la base de datos seguramente ayuda a hacer 
rápido los prototipos", comenta Chip. "No tomó mucho tiempo completar la pantalla. ¿Les 
gustaría verme probar el prototipo?" 

"Claro", contesta Anna. "Ésta es mi parte favorita de la elaboración de prototipos." 

Chip ejecuta el diseño de la pantalla mientras Anna, Mike y Dot observan. Las listas 
desplegables y las casillas de verificación le facilitan ingresar los datos exactos. 

"Realmente me gusta esto", dice Dot. "¿Me permites introducir algunos datos?" 

"Por supuesto", contesta Chip. "Trata de agregar datos inválidos y válidos. Y observa los 
mensajes de ayuda que aparecen en la parte inferior de la pantalla para indicar lo que se de¬ 
be introducir." 

Anna regresa a su escritorio y hace el diseño de la pantalla ADD SOFTWARE 
RECORD. 

Cuando Anna completa el diseño de la pantalla, le pide a Cher que pruebe el prototipo. 
Cher teclea información, verifica los valores de las listas desplegables y visualiza los mensa¬ 
jes de ayuda. 

"Realmente me gusta el diseño de esta pantalla y su apariencia", comenta Cher. "Sin 
embargo, le faltan algunos campos que normalmente se incluyen cuando se introduce un 
paquete de software, como la marca y modelo de la computadora en que se ejecuta el soft¬ 
ware, la memoria, monitor y la impresora o plotter requeridos. También quisiera botones 
para guardar el registro y salir de la pantalla." 
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"No hay problema. Haré los cambios y regresaré contigo", contesta Anna, tomando al¬ 
gunas notas para sí misma. 

Poco tiempo después, Cher prueba nuevamente la pantalla ADD SOFTWARE RE¬ 
CORD. Esta incluye todas las características que ella requiere. El diseño de la pantalla com¬ 
pleta se puede visualizar con Microsoft Access. Observe que una línea separa la información 
del software y las entradas del hardware. 

"Chip, estuve hablando con Dot y mencionó que tiene fondos para poner algo de infor¬ 
mación en la Web, como parte de un sitio Web unificado que brinde apoyo tecnológico en 
la CPU", comenta Anna, apartando la vista de su computadora. "He estado ocupada crean¬ 
do un prototipo para los menús de la página Web y la primera pantalla, donde se puedan 
reportar los problemas de tecnología. Puesto que Mike es el encargado de resolver proble¬ 
mas, los he invitado a él y a Dot para que revisen el prototipo. ¿Quieres unirte a la sesión?" 

"Claro", contesta Chip. "Estoy interesado en trabajar en el diseño de algunas de las pá¬ 
ginas Web." 

Poco tiempo después Mike, Dot y Chip se reúnen con Anna para que les muestre la pá¬ 
gina Web, ilustrada en la figura E6.3. 

"Realmente me gusta el estilo del menú", comenta Dot. "Las fichas de las características 
principales en la parte superior son fáciles de usar y me gusta la forma en que cambian de 
color cuando se hace clic en ellas." 

"Sí, y tener submenús debajo del principal para las características de cada ficha facilita 
encontrar lo que se está buscando", agrega Mike. "Sin embargo, tengo algunas sugerencias 
para reportar los problemas en la página Web. Sería más útil si el área para seleccionar la ca¬ 
tegoría del problema se pasara a la parte superior de la página. Cada tipo de problema se 
asigna a un técnico diferente, que cuente con alguna experiencia en esa área. Necesitamos 
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una casilla de verificación adicional para identificar si el equipo o el software con el que es¬ 
temos trabajando es compatible con Macintosh o con IBM. La ayuda del número de parte 
(Tag Number] es una gran idea. Muchas personas no saben que cada parte de equipo tiene 
una pequeña placa de metal con un número único de inventario. Hmmm... Esa gran área 
azul parece destacar demasiado. Después de todo, sólo es ayuda. Pienso que seria mejor 
reemplazarla con una pequeña imagen." 

"Pienso que será fácil hacer estos cambios", comenta Anna. 

"Excelente", contesta Mike. "También sería útil incluir en la página Web el número tele¬ 
fónico de la línea directa del soporte técnico. Si es una verdadera emergencia, podría ayudar 
a acelerar la resolución del problema. También deberíamos agregar un campo para que intro¬ 
duzcan su número telefónico. Por supuesto, podríamos buscarlo, pero la persona podría estar 
reportando el problema desde un laboratorio de cómputo u otro lugar fuera de su oficina." 

"[Buena ideal", exclama Dot. "Esto será sumamente útil para los profesores y el perso¬ 
nal. Creo que deberíamos crear prototipos de todas las páginas Web del sitio. Estoy cons¬ 
ciente de que las páginas Web cambian de vez en cuando, [pero hagámoslas tan buenas como 
sea posible desde el principio!" 

Anna le echa una mirada a Chip y sonríe. "[Creo que tendrás que trabajar en el diseño 
de las páginas Web más pronto de lo que creías!" 

Anna y Chip continuaron trabajando en los prototipos diseñando, obteniendo retroali- 
mentación del usuario y modificando el diseño para reflejar los cambios del usuario. Ahora 
que el trabajo está terminado, tienen una mejor percepción de los requerimientos del sistema. 

EJERCICSOS 

Revise los prototipos de informe y de pantalla de los siguientes ejercicios (E-l a E-10). Re¬ 
gistre los cambios en una copia del Formulario de Evaluación de Prototipo. Use Microsoft 
Access para visualizar los prototipos, después modifique los prototipos de informe y de 
pantalla con los cambios sugeridos. Imprima los prototipos terminados. 

Use los siguientes lincamientos para guiar su análisis: 

1. Alineación de los campos en los informes. ¿Los campos están alineados correctamente? 
¿Los encabezados de columna del informe están alineados correctamente en las colum¬ 
nas? ¿Si el informe tiene títulos a la izquierda de los campos de datos, están alineados 
correctamente (normalmente a la izquierda)? ¿Los datos están alineados correctamen¬ 
te dentro de cada campo de entrada? 

2. Contenido del informe. ¿El informe contiene todos los datos necesarios? ¿Están los totales 
y subtotales correctos y útiles? ¿En el informe hay totales extra o datos que no deberían 
estar? ¿En el informe se imprimen los códigos o el significado de éstos (los códigos se 
deben evitar debido a que en ocasiones no presentan claramente la información al 
usuario)? 

3. Revise la apariencia visual del informe. ¿Su apariencia es agradable? ¿Los campos repeti¬ 
dos están impresos en grupo (es decir, los datos se deben imprimir una sola vez, al prin¬ 
cipio del grupo)? ¿Hay suficientes líneas en blanco entre los grupos para identificarlos 
fácilmente? 

4. Alineación de los datos y títulos de la pantalla. ¿Los títulos están alineados correctamen¬ 
te en las pantallas? ¿Los campos de datos están alineados correctamente? ¿Los datos 
dentro de un campo están alineados correctamente? 

5. Apariencia visual de la pantalla. ¿La pantalla tiene una apariencia agradable? ¿Hay sufi¬ 
ciente espacio vertical entre los campos? ¿Hay suficiente espacio horizontal entre las 
columnas? ¿Los campos están agrupados lógicamente? ¿Las características, como los 
botones y casillas de verificación, están agrupadas? 
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6. ¿La pantalla contiene todos los elementos funcionales necesarios? Vea si faltanbotones que 
facilitarían el trabajo del usuario con la pantalla; también vea si faltan datos, si hay da¬ 
tos innecesarios o si hay campos que se deben reemplazar con una casilla de verifica¬ 
ción o una lista desplegable. 


E-l. 

0 * E-2. 



•!íf^ E-5. 
# E-6. 


;V>> E-8. 



#’ E-10. 


En la figura E6.4 se muestra el listado HARDWARE INVENTORY LISTING. Este 
listado muestra todas las computadoras personales, clasificadas por campus y salas. 

El informe SOFTWARE INVESTMENT REPORT se usa para calcular la cantidad 
total invertida en el software. 

El INFORME DE COMPUTADORAS INSTALADAS muestra la información de las 
máquinas instaladas. 

El prototipo del informe COMPUTER PROBLEM REPORT clasifica todas las má¬ 
quinas por el costo total de reparaciones e incluye el número de éstas (debido a que 
algunas máquinas aún tienen garantía, no es tan elevado su costo). Este prototipo se 
usa para calcular el costo total de las reparaciones en toda la universidad, así como 
también para identificar las máquinas que tienen problemas. 

El informe NEW SOFTWARE INSTALLED REPORT muestra el número de máqui¬ 
nas con cada paquete de software que están instaladas en cada sala de cada campus. 
El informe SOFTWARE CROSS-REFERENCE REPORT menciona todas las ubica¬ 
ciones para cada versión de cada paquete de software. 

La pantalla DELETE COMPUTER RECORD se usa para quitar computadoras del 
sistema. El área de entrada es el campo Hardware Inventory Number. Los otros campos 
únicamente son de despliegue, para identificar la máquina. A los usuarios les gustaría 
poder imprimir cada registro antes de que se eliminen. También desean desplazarse a 
los registros siguientes y anteriores. Sugerencia: Examine los campos mostrados en el 
informe HARDWARE INVENTORY LISTING. 

Una pantalla UPDATE MAINTENANCE INFORMATION permite a Mike Crowe 
cambiar la información de mantenimiento de las computadoras personales. Algunas 
veces éstos son cambios de rutina, tales como LAST PREVENTIVE MAINTENAN- 
CE DATE o NUMBER OF REPAIRS, pero otros cambios podrían ocurrir sólo ocasio¬ 
nalmente, tales como el vencimiento de una garantía. El HARDWARE INVENTORY 
NUMBER se introduce, y se encuentra el registro COMPUTER RECORD corres¬ 
pondiente. Se despliegan la marca y el modelo para retroalimentación. El operador 
podría cambiar después los campos WARRANTY, MAINTENANCE INTERVAL, 
NUMBER OF REPAIRS, LAST PREVENTIVE MAINTENANCE DATE y TOTAL 
COST OF REPAIRS. A Mike le gustaría imprimir la información de la pantalla, así 
como también deshacer cualquier cambio, fácilmente. 

La SOFTWARE LOCATION INQUIRY despliega la información de las salas y de las 
máquinas que contienen el software seleccionado. Se introducen la información de 
TITLE, VERSIÓN NUMBER y OPERATING SYSTEM. Una parte de la información 
de la pantalla debe mostrar la información sobre CAMPUS LOCATION, ROOM 
LOCATION, HARDWARE INVENTORY NUMBER, BRAND ÑAME y MODEL. 
Los botones permiten al usuario ir al registro siguiente, al registro anterior y cerrar y 
salir de la pantalla. 

La HARDWARE CHARACTERISTICS INQUIRY se usa para localizar máquinas 
con ciertas características de hardware. El operador introduce un tipo de marca y de 
unidad DE CD-ROM. Los campos MONITOR y PRINTER CODE tienen listas des¬ 
plegables para seleccionar los códigos adecuados. La parte desplegada de la pantalla 
de consulta consiste en CAMPUS, ROOM e INVENTORY NUMBER. 




JÜ! Los ejercicios precedidos por un ¡cono Web indican que en el sitio Web de este libro hay material con valor 
agregado. 
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VA analista di--.¡K¡cnuu>. necesita anrowehar la: libertad conceptual que ponen VI su.alcana^; 
los dia.tiiv.nv.s dé [lujo de dalos, los cuales representan ¿ráucamente los procesos.-y flujo de 
líalos del sistema di'. un negocio. V.n su estado origina!, los diímrámas de finjo de datos des¬ 
criben. de la Tunna más amplia* el panorama general dé las entradas, procesos y salidas del 
sisuóna, que corresponden á lós del modelo general de r >ÍsLemas discutido en el capitulo 2. 
Se puede usií.una:serie de diagramas de linio de dalos én tapas para represenmr V analizar 
los nroivdiniienlo.-.- delall.idos en el sisjeina Final. p 


ENFOQUE DEL FLUJO DE DATOS PARA DETERMINAR 
LOS REQUERIMIENTOS 

Cuando los analizas de sistemas internan entender los requerimientos de información de 
h> usuarios, deber tener la líip-.idd.cd de visuali/ar lomo se mtiown los. chitos en la organi¬ 
zación. lo* protesos o iraiislonnacioncs que sufren dichos datos y cuáles son los resultados. 
j\ffi'qüV;í¿S.éntf¿vjStóS'y, la rn vesügatión de datos reales V concretos proporcionan una des- 
rriiviñn verbal del sisíéma. una iléirípiíón visual puede consolidar esta- información dé .; 
manera í>,isu:n¡e útil. - 'J:’ 5 '''-- - ’ tVc''” 

Li analista de sistenms puede elaborar una representación grúlica de los procesos que se'’' 
realizan con los datos en toda la organización, mediante una técnica de análisis estructura¬ 
da llamada diagramas de flujo de datos (DFDs). Con el uso de tan sólo cuatro símbolos, el : 
analista de sistemas puede crear Una descripción gráfica de los procesos qué, con el tiempo, 
contribuirán a desarrollar una solida documentación del sistema ■ ' ■ : 


USO DE DIAGRAMAS 
DE FLUJO DE DATOS 






























VENTAJAS DEL ENFOQUE DEL FLUJO DE DATOS 


El enfoque del flujo de datos posee cuatro ventajas principales sobre las explicaciones des¬ 
criptivas en relación con la forma en que los datos se mueven a través del sistema: 

1. Libertad para emprender la implementación técnica del sistema en las etapas tempranas. 

2. Una comprensión más profunda de la interrelación entre sistemas y subsistemas. 

3. Comunicar a los usuarios el conocimiento sobre el sistema actual mediante diagramas 
de flujo de datos. 

4. Análisis de un sistema propuesto para determinar si se han definido los datos y proce¬ 
sos necesarios. 

Quizás la ventaja más grande es la libertad conceptual para utilizar los cuatro símbolos (que 
se verá en la próxima subsección sobre las convenciones de DFD}. (Usted reconocerá tres 
de los símbolos que se emplearon en el capítulo 2.) Ninguno de los símbolos especifica los 
aspectos físicos de la implementación. Los DFDs hacen énfasis en el procesamiento o la 
transformación de datos conforme éstos pasan por una variedad de procesos. En los DFDs 
lógicos no hay distinción entre procesos manuales o automatizados. Los procesos tampoco 
se representan gráficamente en orden cronológico. En vez de ello, se agrupan sólo si el aná¬ 
lisis detallado dicta que tiene sentido hacerlo. Los procesos manuales se agrupan, y los 
procesos automatizados también se pueden agrupar. Este concepto, llamado partiáonamien- 
to, se trata en una sección posterior. 


CONVENCIONES USADAS EN LOS DIAGRAMAS DE FLUJO DE DATOS 

En los diagramas de flujo de datos se usan cuatro símbolos básicos para graficar el movi¬ 
miento de los datos: un cuadrado doble, una flecha, un rectángulo con esquinas redondea¬ 
das y un rectángulo abierto (cerrado en el lado izquierdo y abierto en el derecho), como se 
muestra en la figura 7.1. Con la combinación de estos cuatro símbolos se puede describir 
gráficamente un sistema completo y varios subsistemas. 
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El cuadrado doble se usa para describir una entidad externa (otro departamento, un 
negocio, una persona o una máquina] que puede enviar datos al sistema o recibirlos de él. 
La entidad externa, o sólo entidad, también se llama origen o destino de datos, y se consi¬ 
dera externa al sistema descrito. A cada entidad se le asigna un nombre adecuado. Aunque 
interactúa con el sistema, se considera fuera de los límites de éste. Las entidades se deben 
designar con un nombre. La misma entidad se podría usar más de una vez en un diagrama de 
flujo de datos en particular para evitar que las líneas se crucen en el flujo de datos. 

La flecha muestra el movimiento de los datos de un punto a otro, con la punta de la fle¬ 
cha señalando hacia el destino de los datos. Los flujos de datos que ocurren simultáneamen¬ 
te se pueden describir mediante flechas paralelas. Una flecha también se debe describir con 
un nombre, debido a que representa los datos de una persona, lugar o cosa. 

Un rectángulo con esquinas redondeadas se usa para mostrar la presencia de un proce¬ 
so de transformación. Los procesos siempre denotan un cambio en los datos o una transfor¬ 
mación de éstos; por lo tanto, el flujo de datos que sale de un proceso siempre se designa de 
forma diferente al que entra en él. Los procesos representan trabajo que se realiza en el sis¬ 
tema y se deben nombrar usando uno de los formatos siguientes. Un nombre claro permite 
reconocer fácilmente lo que hace un proceso. 

1. A los procesos de alto nivel asígneles el nombre del sistema. Por ejemplo, SISTEMA 
DE CONTROL DE INVENTARIOS. 

2. Para nombrar un subsistema principal, use un nombre como SUBSISTEMA DE IN¬ 
FORMACIÓN DE INVENTARIOS o SISTEMA DE CUMPLIMIENTO DE PEDI¬ 
DOS DEL CLIENTE EN INTERNET 

3. Para los procesos detallados use un formato de sustantivo-verbo-adjetivo. El sustantivo 
indica cuál es el resultado principal del proceso, tal como INFORME o REGISTRO. El 
verbo describe el tipo de actividad, tal como CALCULAR, VERIFICAR, PREPARAR, 
IMPRIMIR o AGREGAR. El adjetivo describe el resultado específico que se produce, 
tal como NUEVO PEDIDO o INVENTARIO. Ejemplos de nombres completos de 
procesos son CALCULAR IMPUESTOS DE VENTAS, VERIFICAR ESTADOS DE 
CUENTA DEL CLIENTE, PREPARAR FACTURA DE ENVÍO, IMPRIMIR INFORME 
DE NUEVOS PEDIDOS, ENVIAR CONFIRMACIÓN AL CLIENTE POR CO¬ 
RREO ELECTRÓNICO, VERIFICAR SALDO DE TARJETA DE CRÉDITO y 
AGREGAR REGISTRO DE INVENTARIO. 

A un proceso también se le debe dar un número de identificación único y exclusivo, que 
indique su nivel en el diagrama. Esta organización se explica más adelante en este mismo 
capítulo. Podría haber varios flujos de datos que entren y salgan de cada proceso. Los pro¬ 
cesos con solo un flujo de entrada y salida se deben examinar en busca de flujos de datos 
perdidos. 

El último símbolo básico usado en los diagramas de flujo de datos es el rectángulo 
abierto, el cual representa un almacén de datos. El rectángulo se dibuja con dos líneas 
paralelas cerradas por una línea corta del lado izquierdo, y abiertas del derecho. Estos sím¬ 
bolos se dibujan con el espacio suficiente para que quepan las letras de identificación en¬ 
tre las líneas paralelas. En los diagramas de flujo de datos lógicos no se especifica el tipo 
de almacenamiento físico. En este punto el símbolo del almacén de datos simplemente 
muestra un lugar de depósito para los datos que permite examinar, agregar y recuperar 
datos. 

El almacén de datos podría representar un almacén manual, tal como un gabinete de 
archivo, o un archivo o una base de datos de computadora. A los almacenes de datos se les 
asigna un nombre debido a que representan a una persona, lugar o cosa. Los almacenes de 
datos temporales, tales como papel borrador o un archivo temporal de computadora, no se 
incluyen en el diagrama de flujo de datos. Para identificar el nivel del almacén de datos, a ca¬ 
da uno asígnele un número de referencia único, tal como DI, D2, D3, etc., como se descri¬ 
be en la siguiente sección. 


USO DE DIAGRAMAS DE FLUJO DE DATOS 


•¡nl&iiia f¡ 




DESARROLLO DE DIAGRAMAS DE FLUJO DE DATOS 


Los diagramas de flujo de datos se pueden y deben dibujar de manera sistemática. La figura 
7.2 sintetiza los pasos para desarrollar eficazmente diagramas de flujo de datos. Primero, el 
analista de sistemas necesita visualizar los flujos de datos desde una perspectiva jerárquica 
de arriba hacia abajo. 

Para empezar un diagrama de flujo de datos, sintetice la narrativa (o historia) del siste¬ 
ma de la organización a una lista con las cuatro categorías de entidad externa, flujo de da¬ 
tos, proceso y almacén de datos. Esta lista a su vez le ayudará a determinar los límites del 
sistema que describirá. Una vez que haya recopilado una lista básica de elementos de datos, 
empiece a dibujar un diagrama de contexto. 

CREACIÓN DEL DIAGRAMA DE CONTEXTO 

Con un enfoque jerárqtiico de arriba hacia abajo para diagramar el movimiento de los datos, 
los diagramas van de lo general a lo específico. Aunque el primer diagrama ayuda al analista 
de sistemas a entender el movimiento básico de los datos, lo general de su naturaleza limita 
su utilidad. El diagrama de contexto inicial debe mostrar un panorama global que incluya 
las entradas básicas, el sistema general y las salidas. Este diagrama será el más general, con 
una visión muy superficial del movimiento de los datos en el sistema y una visualización lo 
más amplia posible del sistema. 

El diagrama de contexto es el nivel más alto en un diagrama de flujo de datos y contie¬ 
ne un solo proceso, que representa a todo el sistema. Al proceso se le asigna el número ce¬ 
ro. En el diagrama de contexto se muestran todas las entidades externas, así como también 
los flujos de datos principales que van desde y hacia dichas entidades. El diagrama no con- 
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tiene ningún almacén de datos. Para el analista es bastante simple crearlo una vez que cono¬ 
ce las entidades externas y el flujo de datos desde y hacia ellas. 


DIBUJO DEL DIAGRAMA 0 (EL SIGUIENTE NIVEL) 

Al "ampliar los diagramas" se puede lograr un mayor detalle que con los diagramas de con¬ 
texto. Las entradas y salidas especificadas en el primer diagrama permanecen constantes en 
todos los diagramas siguientes. Sin embargo, el resto del diagrama original se amplía para in¬ 
cluir de tres a nueve procesos y mostrar almacenes de datos y nuevos flujos de datos de me¬ 
nor nivel. El efecto es similar al de tomar una lupa para ver el diagrama de flujo de datos 
original. Cada diagrama ampliado debe ocupar una sola hoja de papel. Al ampliar los DFDs 
para representar subprocesos, el analista de sistemas empieza a completar los detalles del 
movimiento de los datos. El manejo de excepciones se ignora en los primeros dos o tres ni¬ 
veles de la diagramación del flujo de datos. 

El Diagrama 0 es la ampliación del diagrama de contexto y puede incluir hasta nueve 
procesos. Si se incluyen más procesos en este nivel se producirá un diagrama difícil de en¬ 
tender. Por lo general, cada proceso se numera con un entero, empezando en la esquina 
superior izquierda del diagrama y terminando en la esquina inferior derecha. En el Diagra¬ 
ma 0 se incluyen los principales almacenes de datos del sistema (que representan a los ar¬ 
chivos maestros) y todas las entidades externas. La figura 7.3 representa gráficamente el 
diagrama de contexto y el Diagrama 0. 

Debido a que un diagrama de flujo de datos es bidimensional (en lugar de lineal), usted 
puede empezar en cualquier punto del diagrama e ir hacia adelante o hacia atrás. Si no está 
seguro de lo que podría incluir en cualquier punto, tome una entidad externa, un proceso o 
un almacén de datos diferente y empiece a dibujar el flujo a partir de él: 

1. Empiece con el flujo de datos de una entidad en el lado de la entrada. Haga preguntas 
tales como: "¿Qué sucede con los datos que entran en el sistema?" "¿Se almacenan?" 
"¿Esta entrada es para varios procesos?" 

2. Trabaje hacia atrás a partir de un flujo de datos de salida. Examine los campos de salida 
de un documento o pantalla. (Este enfoque es más sencillo si se han creado prototipos.) 
Pregunte sobre cada campo de la salida: "¿De dónde viene?" o "¿Se calcula o almacena 
en un archivo?" Por ejemplo, cuando la salida es un RECIBO DE NÓMINA, el NOM¬ 
BRE DEL EMPLEADO y la DIRECCIÓN se podrían localizar en un archivo EM¬ 
PLEADO, las HORAS TRABAIADAS podrían encontrarse en un REGISTRO DEL 
TIEMPO y el SUELDO BRUTO y las DEDUCCIONES se tendrían que calcular. Ca¬ 
da archivo y registro estaría conectado al proceso que produce el recibo de nómina. 

3. Examine el flujo de datos desde o hacia un almacén de datos. Pregunte: "¿Qué procesos 
ponen los datos en el almacén?" o "¿Qué procesos usan los datos?" Observe que un al¬ 
macén de datos utilizado en el sistema en el que esté usted trabajando podría ser pro¬ 
ducido por un sistema diferente. Por lo tanto, desde su punto de vista, tal vez no haya 
ningún flujo de datos hacia el almacén de datos. 

4. Analize un proceso bien definido. Vea qué entrada de datos necesita el proceso y qué 
salida produce. Después vincule la entrada y la salida con los almacenes de datos y las 
entidades adecuadas. 

5. Tome nota de cualquier área confusa en donde no esté seguro de lo que se debe incluir 
o de la entrada o la salida que se requiera. Al conocer las áreas problemáticas podrá rea¬ 
lizar una lista de preguntas para las entrevistas de seguimiento con los usuarios clave. 


CREACIÓN DE DIAGRAMAS HIJOS (NIVELES MÁS DETALLADOS) 

Cada proceso del Diagrama 0 se puede, a su vez, ampliar para crear un diagrama hijo más 
detallado. El proceso del Diagrama 0 a partir del cual se realiza la ampliación se llama pro¬ 
ceso padre, y el diagrama que se produce se llama diagrama hijo. La regla principal para 
crear diagramas hijos, el equilibrio vertical, estipula que un diagrama hijo no puede produ¬ 
cir salida o no puede recibir entrada que el proceso padre no produzca o reciba también. 
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Todos los flujos de datos hacia dentro o hacia fuera del proceso padre se deben mostrar flu¬ 
yendo hacia dentro o hacia fuera del diagrama hijo. 

Al diagrama hijo se le asigna el mismo número que a su proceso padre en el Diagrama 0. 
Por ejemplo, el proceso 3 se podría ampliar para crear el Diagrama 3. Los procesos del dia¬ 
grama hijo se numeran usando el número del proceso padre, un punto decimal y un solo 
número para cada proceso hijo. Los procesos del Diagrama 3 se podrían numerar como 3.1, 
3.2, 3.3, etc. Esta convención permite al analista localizar una serie de procesos a través de 
muchos niveles de ampliación. Si el Diagrama 0 presenta los procesos 1, 2 y 3, los diagramas 
hijos 1, 2 y 3 estarán en el mismo nivel. 

Por lo regular las entidades no se muestran en los diagramas hijos debajo del Diagra¬ 
ma 0. El flujo de datos que coincide con el flujo padre se llama flujo de datos de interfaz y se 
representa con una flecha que parte de un área vacía del diagrama hijo. Si el proceso padre 
tiene un flujo de datos conectado a un almacén de datos, también el diagrama hijo podría 
incluir el almacén de datos. Además, este diagrama de nivel inferior podría contener alma¬ 
cenes de datos que no se muestran en el proceso padre. Por ejemplo, se podría incluir un ar¬ 
chivo que contenga una tabla de información, como una tabla de impuestos, o un archivo 
que conecta dos procesos del diagrama hijo. En un diagrama hijo se podría incluir un flujo 
de datos de nivel inferior, como una línea de error, aunque no se podría hacer lo mismo en 
el proceso padre. 
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Los procesos se podrían ampliar o no ampliar, dependiendo de su nivel de complejidad. 
Cuando no se amplía un proceso, se dice que es funcionalmente primitivo y se llama proce¬ 
so primitivo. Se escribe lógica para describir estos procesos y en el capítulo 9 se explica en 
detalle. La figura 7.4 ilustra niveles detallados de un diagrama de flujo de datos hijo. 


Diferencias entre el diagrama 
padre (arriba) y el diagrama 
hijo (abajo). 


REVISIÓN DE ERRORES EN LOS DIAGRAMAS 

Cuando se dibujan diagramas de flujo de datos se pueden cometer varios errores comunes 
como los siguientes: 

1. Olvidar incluir un flujo de datos o apuntar con una flecha en la dirección incorrecta. 
Un ejemplo es un proceso dibujado que muestra todos sus flujos de datos como entra¬ 
da o salida. Cada proceso transforma datos y debe recibir una entrada y producir una 
salida. Este tipo de error ocurre generalmente cuando el analista olvida incluir un flujo 
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de datos o coloca una flecha que apunta en la dirección incorrecta. El proceso 1 de la 
figura 7.5 sólo contiene entrada porque la flecha del SUELDO BRUTO apunta en la di¬ 
rección incorrecta. Este error también afecta al proceso 2, CALCULAR CANTIDAD 
DE RETENCION, al cual le falta además un flujo de datos que represente entrada pa¬ 
ra las tasas de retención y el número de dependientes. 

2. Conectar directamente entre sí almacenes de datos y entidades externas. Los almacenes 
de datos y las entidades externas no se deben conectar entre sí; sólo se deben conectar 
con un proceso. Un archivo no interactúa con otro archivo sin la ayuda de un programa 
o una persona que mueva los datos, de tal manera ARCHIVO MAESTRO DE EM¬ 
PLEADOS no puede producir directamente el archivo CONCILIACIÓN DE CHE¬ 
QUES. Las entidades externas no trabajan directamente con los archivos. Por ejemplo, a 
usted no le gustaría que un cliente hurgara en el archivo maestro de clientes. Por lo tan¬ 
to, el EMPLEADO no crea el ARCHIVO DE TIEMPO DEL EMPLEADO. Dos enti¬ 
dades externas conectadas directamente indican que desean comunicarse entre sí. Esta 
conexión no se incluye en el diagrama de flujo de datos a menos que el sistema facilite 
la comunicación. La elaboración de un informe es un ejemplo de esta clase de comuni¬ 
cación. Sin embargo, es necesario interponer un proceso entre las entidades para producir 
el informe. 

3. Asignar nombres incorrectos a los procesos o al flujo de datos. Revise el diagrama de 
flujo de datos para asegurar que cada objeto o flujo de datos tiene un nombre adecua- 
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do. Un proceso debe indicar el nombre del sistema o usar el formato sustantivo-verbo- 
adjetivo. Cada flujo de datos se debe describir con un sustantivo. 

4. Incluir más de nueve procesos en un diagrama de flujo de datos. La inclusión de dema¬ 
siados procesos origina un diagrama confuso difícil de entender y obstaculiza la comu¬ 
nicación en lugar de facilitarla. Si en un sistema existen más de nueve procesos, agrupe 
en un subsistema algunos de los procesos que trabajan en conjunto y póngalos en un 
diagrama hijo. 

5. Omitir un flujo de datos. Examine su diagrama en busca de flujo lineal, es decir, flujo 
de datos en el cual cada proceso tiene sólo una entrada y una salida. El flujo de datos 
lineal no es muy común, excepto en los diagramas de flujo de datos hijos muy deta¬ 
llados. Su presencia normalmente indica que al diagrama le falta algún flujo de datos. 
Por ejemplo, el proceso CALCULAR CANTIDAD DE RETENCIÓN necesita como 
entrada el número de dependientes que tiene un empleado y las TASAS DE RETEN¬ 
CIÓN. Además, el SUELDO NETO no se puede calcular únicamente con la RE¬ 
TENCIÓN, y el RECIBO DE NÓMINA DEL EMPLEADO no se puede crear tan 
sólo con el SUELDO NETO; también se necesita incluir un NOMBRE DEL EM¬ 
PLEADO, así como con las cifras de la nómina actual hasta la fecha y la CANTIDAD 
DE RETENCIÓN. 

6. Crear una separación (o ampliación) desequilibrada en los diagramas hijos. Cada dia¬ 
grama hijo debe tener el mismo flujo de datos de entrada y salida que el proceso pa¬ 
dre. Una excepción a esta regla son las salida menores, como las líneas de error, que se 
incluyen solamente en el diagrama hijo. El diagrama de flujo de datos de la figura 7.6 
está bien dibujado. Observe que aunque el flujo de datos no es lineal, usted puede se¬ 
guir con toda claridad una ruta directamente desde la entidad de origen a la entidad 
de destino. 


DIAGRAMAS DE 'FLUJO' DE’ b^ LÓGICOS Y FISICOS 

Los diagramas de flujo de datos se catalogan como lógicos o físicos. Un diagrama de flu¬ 
jo de datos lógico se enfoca en el negocio y en el funcionamiento de éste. No se ocupa de 
la manera en que se construirá el sistema. Más bien, describe los eventos que ocurren en 
el negocio y los datos requeridos y producidos por cada evento. Por el contrario, un dia¬ 
grama de flujo de datos físico muestra cómo se implementará el sistema, incluyendo el 
hardware, el software, los archivos y las personas involucradas en el sistema. En la figura 
7.7 se muestra un cuadro que compara las características de los modelos lógico y físico. 

Observe que el modelo lógico refleja el negocio, mientras que el modelo físico describe 
el sistema. 

En teoría, los sistemas se desarrollan mediante el análisis del sistema actual (DFD lógi¬ 
co actual) y después se agregan características que el nuevo sistema debe incluir (DFD ló¬ 
gico propuesto). Por último, se deben desarrollar los mejores métodos para implementar el 
nuevo sistema (DFD físico). En la figura 7.8 se muestra esta progresión. 

El desarrollo de un diagrama de flujo de datos lógico para el sistema actual ofrece un 
entendimiento claro de su funcionamiento, y por lo tanto un buen punto de partida para 
desarrollar el modelo lógico del mismo. Con frecuencia este paso, que requiere una conside¬ 
rable cantidad de tiempo, se omite para ir directamente al DFD lógico propuesto. Las gráfi¬ 
cas de navegación para los sitios Web que se crean con Microsoft FrontPage constituyen un 
ejemplo de un tipo de modelo lógico. 

Una ventaja de construir el diagrama de flujo de datos lógico del sistema actual es que 
se puede usar para crear el diagrama de flujo de datos lógico del nuevo sistema. Los proce¬ 
sos innecesarios en el nuevo sistema se podrían eliminar y agregar nuevas características, 
actividades, salidas, entradas y datos almacenados. Mediante este enfoque se garantiza que 
el nuevo sistema conservará las características esenciales del sistema anterior. Además, el 
uso del modelo lógico del sistema actual como base para el sistema propuesto ofrece una 
transición gradual para el diseño del nuevo sistema. Una vez desarrollado el modelo lógico 
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para el nuevo sistema, se podría usar para crear un diagrama de flujo de datos físico para 
tal sistema. 


La figura 7.9 muestra un diagrama de flujo de datos lógico y uno físico para el cajero de 
una tienda de abarrotes. El CLIENTE lleva los ARTÍCULOS a la caja; se CONSULTAN los 
PRECIOS de todos los ARTÍCULOS y se totalizan; después, se PAGA al cajero; por último, 
se da un RECIBO al CLIENTE. El diagrama de flujo de datos lógico ilustra los procesos in¬ 
volucrados sin detallar la implementación física de las actividades. El diagrama de flujo de 
datos muestra que se usa un código de barras —el código universal del producto (UPC), 
CÓDIGO DE BARRAS, que se encuentra en la mayoría de los artículos de las tiendas de 
abarrotes—. Además, el diagrama de flujo de datos físico menciona los procesos manuales 
tal como escanear, explica que se usa un archivo temporal para mantener un subtotal de los 
artículos, e indica que el PAGO se puede hacer con EFECTIVO, CHEQUE o TARJETA DE 
DÉBITO. Finalmente, se refiere al recibo por su nombre, RECIBO DE LA CAJA REGIS¬ 
TRADORA. 
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Característica de diseño 

Lógico 

Físico 

. Qué describe 
el modelo 

T Cómo funciona 
el nogoco... 

Como se implementara-el sistema 
(o cómo funciona el sistema actual) . 

Qué representan 
los procesos 

Las actividades 
del negocio. 

Programas, módulos del programa 
y procedimientos manuales. 

Qué representan los 
almacenes de datos 1 

Colecciones de datos ■ 

1 independientemente de 
cómose almacenan. 

Archivos y bases de datos físicos, archivos' 
manuales. ' 2>'i L - VT ■; ;■ ■ i 

Tipo de almacenes 
de datos 

Muestra almacenes de 
datos que representan 
colecciones de datos 
permanentes. 

Archivos maestros, archivos de transición. 
Cualesquier procesos que operen en dos 
momentos diferentes deben conectarse 
mediante un almacén de datos. 

Controles del sistema L : 

Muestra los controles 
. del negocio. 

Muestra controles para validar los datos 
de entrada, para obtener un registro .(el 
estado de un registro), para asegurar 


T; . _ la realización exitosa de un proceso y. 

para la seguridad del sistema (ejemplo: 
registros de una cuenta de diario). - 



DESARROLLO DE DIAGRAMAS DE FLUJO DE DATOS LÓGICOS 

Para desarrollar un diagrama de este tipo, primero construya un diagrama de flujo de datos pa¬ 
ra el sistema actual. Hay varias ventajas al usar un modelo lógico, entre ellas: 

1. Mejor comunicación con los usuarios. 

2. Sistemas más estables. 

3. Mejor entendimiento del negocio por parte de los analistas. 

4. Flexibilidad y mantenimiento. 

5. Eliminación de redundancias y creación más sencilla del modelo físico. 

Es más fácil usar un modelo lógico al comunicarse con los usuarios del sistema porque se 
centra en las actividades del negocio. En consecuencia, los usuarios estarán familiarizados 
con las actividades principales y con muchos de los requerimientos de información de cada 
actividad. 



Obtenga el diagrama de flujo 
de datos lógico para el sistema 
actual examinando el diagrama 
de flujo de datos físico y 
separando las actividades únicas 
del negocio. 

Cree el diagrama de flujo de datos 
lógico para el nuevo sistema 
agregando al diagrama de flujo 
de datos lógico del sistema actual 
las entradas, salidas y procesos 
requeridos en el nuevo sistema. 


Obtenga el diagrama de flujo 
de datos físico examinando los 
nuevos procesos en el nuevo 
diagrama lógico. Determine en 
dónde deben existir las interfaces 
de usuario, la naturaleza de los 
procesos y los almacenes de 
datos necesarios. 


La progresión del los modelos 
lógicos a físicos. 
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Diagrama de flujo de datos lógico 




Con frecuencia, los sistemas desarrollados con un diagrama de flujo de datos lógico son 
más estables porque se basan en los eventos del negocio y no en una tecnología o método 
particular de implementación. Los diagramas de flujo de datos lógicos representan caracte¬ 
rísticas de un sistema que deberían existir sin importar cuáles sean los medios físicos para 
llevarlas a cabo. Por ejemplo, las actividades tales como solicitar una credencial de socio de 
un videocentro, rentar un DVD y devolverlo, podrían realizarse aunque el establecimiento 
tenga un sistema automatizado, manual o híbrido. 

DESARROLLO DE DIAGRAMAS DE FLUJO DE DATOS FÍSICOS 

Después de desarrollar el modelo lógico del nuevo sistema, usted lo podría usar para crear 
un diagrama de flujo de datos físico. El diagrama de flujo de datos físico muestra cómo se 
creará el sistema, y generalmente contiene la mayoría, si no es que todos, de los elementos 
de la figura 7.10. Así como los diagramas de flujo de datos lógicos tienen ciertas ventajas, los 
diagramas de flujo de datos físicos tienen otras, entre ellas: 

1. Aclarar qué procesos son manuales y cuáles son automatizados. 

2. Describir los procesos con mayor detalle los DFDs lógicos. 

3. Distribuir en un orden particular los procesos que se deben realizar. 

4. Identificar los almacenes de datos temporales. 

5. Especificar los nombres reales de archivos y documentos impresos. 

6. Agregar controles para asegurar que los procesos se realicen adecuadamente. 



El diagrama de flujo de datos 
físico (abajo) muestra ciertos 
detalles que no se encuentran 
en el diagrama de flujo de datos 
lógico (arriba). 
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Contenido de los diagramas de flujo de datos físicos 

° Procesos manuales- - i' L' ■ • , ,fp '■ l.a,;. 

• -Procesos para agregar, eliminar; cambiar y actualizar registras ; : i 

• Procesos de, entrada y verificación de datos 

• Procesos de validación para garantizar la precisión de la. entrada de datos 


I HUI I Ii*»i oo aiyinvu pene* ciM icu .yaiyo .1 • . ; t . 

• Controles para describir la terminación de tareas o condiciones de errar 



Los diagramas de flujo de datos, 
físicos contienen muchos 
elementos que no se encuentran 
en los diagramas de flujo de 
datos lógicos. 


Los diagramas de flujo de datos físicos son a menudo más complejos que los diagramas de 
flujo de datos lógicos debido a la gran cantidad de almacenes de datos que incluye un sistema. 
Con frecuencia se utilizan las siglas CLAE (CRUD: Créate, Read, Update and Deleté) para 
denotar las actividades Crear, Leer, Actualizar y Eliminar, que un sistema debe ejecutar en 
cada archivo maestro. Una matriz CLAE es una herramienta que sirve para representar en qué 
parte del sistema ocurre cada uno de estos procesos. La figura 7.11 es una matriz CLAE pa¬ 
ra una tienda virtual de Internet. Observe que algunos de los procesos incluyen más de una 
actividad. Los procesos de entrada de datos como codificar y verificar también son parte de 
los diagramas de flujo de datos físicos. 

Los diagramas de flujo de datos físicos también tienen almacenes de datos intermedios, 
con frecuencia un archivo de transacción o una tabla de base de datos temporal. A menudo, 
los almacenes de datos intermedios consisten en archivos de transacción que se utilizan para 
almacenar datos entre procesos. Dado que es poco probable que la mayoría de los procesos 
que requieren acceso a un conjunto determinado de datos se ejecuten al mismo tiempo, los 
archivos de transacción deben guardar los datos de un proceso para luego enviarlo al si¬ 
guiente. Un ejemplo fácil de entender de este concepto se encuentra en las experiencias co¬ 
tidianas relacionadas con la compra de comestibles, la preparación de la comida y la comida 
misma. Estas actividades son: 

1. Escoger los artículos de los estantes. 

2. Realizar el pedido y pagar la factura. 

3. Transportar los comestibles a casa. 

4. Preparar la comida. 

5. Ingerir la comida. 



Registro del : .cliente 
Análisis de artículos 
Selección de artículos 
Realizar el pedido 
: Sumar cuenta. 




Matriz CLAE para, una tienda 
virtual en Internet. Esta ; ■ >. '■ 
herramienta sirve para representar 
en qué parte de un. sistema 
' ocurre cada uño de los siguientes 
cuatro procesos Crear.. Leer, 

: Actualizar y E ¡m'nar. 




' ; 7Ca:v : Lu A 


Agregar articulo 
Cerrar cuenta dél cliente , 




Eliminar artículo obsoleto 


Cambiar datos demográficos del cliente LA-, 




Cambiar pedido del cliente 


LA CLAE 


Análisis del pedido 
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Tabla de eventos de respuesta 
para una tienda virtual en Internet. 


Cada una de estas cinco actividades se representaría mediante un proceso separado en un 
diagrama de flujo de datos físico, y cada una ocurre en un momento diferente. Por ejemplo, 
usted nunca transportaría los comestibles a casa y los comería al mismo tiempo. Por consi¬ 
guiente, se requiere un "almacén de datos de transacciones" para enlazar cada tarea. Cuando 
usted selecciona artículos, el carrito de compras cumple la función de almacén de datos de 
transacciones. Después del siguiente proceso [realizar el pedido], el carrito de compras ya 
no es necesario. El almacén de datos de transacciones que enlaza el pago del pedido y el 
transporte de los comestibles a casa es la bolsa de compras ([más barato que dejar que usted 
se lleve a casa el carrito de compras!}. Las bolsas constituyen una forma ineficiente de alma¬ 
cenar comestibles una vez que los tiene en casa, así que se utilizan alacenas y refrigeradores 
como almacén de datos de transacciones entre la actividad de transportar los comestibles 
a casa y la preparación de la comida. Por último, un plato, un tazón y una taza constituyen 
el enlace entre preparar la comida e ingerirla. 

También se puede incluir información relacionada con el tiempo. Por ejemplo, un DFD 
físico podría indicar que un programa de edición se debe ejecutar antes que un programa de 
actualización. Las actualizaciones deben ejecutarse antes que la elaboración de un informe 
resumido, o un pedido debe ingresarse en un sitio Web antes de verificar con la institución 
financiera la cantidad cargada a una taijeta de crédito. A causa de estas consideraciones, un 
diagrama de flujo de datos físico podría tener una apariencia más lineal que la de un mode¬ 
lo lógico. 

Cree el diagrama de flujo de datos físico para un sistema mediante el análisis de su en¬ 
trada y su salida. Al crear un diagrama de flujo de datos físico, el flujo de datos de entrada 
proveniente de una entidad externa en ocasiones se denomina detonador porque inicia las 
actividades de un proceso, y el flujo de datos de salida de una entidad externa se denomina 
respuesta porque se envía como resultado de alguna actividad. Determine qué campos o 
elementos de datos es necesario teclear. Estos campos se denominan elementos básicos y se 


Evento 

Origen 

Detonador 

Actividad 

Respuesta 

Destino 

El cliente 
se registra 

Cliente 

Número y contraseña 
del cliente 

Encontrar registro del cliente : 
y verificar su contraseña!; : : í p 
Enviar página Web de .;> :: 

bienvenida. . : 0 . 

:Página:We¥ "y, -.. 

: de bienvenida' 

Cliente 

El cliente explora 
los artículos de la 

tienda virtual 

en Web 

Cliente 

Información de artículo 

Encontrar precio y cantidad 
disponible del artículo. 

Enviar página Web de 
respuesta sobre el artículo. 

Página Web 
de respuesta 
sobre el artículo 

Cliente 

El cliente coloca 
ártículos en la 
: canasta de compras: 
de/la tienda virtual 

en Web: .1 

: Cliente 

> 

Compra del artículo 
(número y cantidad 
del artículo) 

Almacenar datos eníél registro" 
;,dé detalles;;dei;:ped¡db.: : í:¿ -S 
Calculare! costo delenyíp-'s 
mediante Jas tablasde .envíos../;,:.- 
Actual izar total d e 1 - el i etnteí r *s>;" 
Actualizarla cantidad dé: y :#: 
artícülos:dlspdh¡b1 es,: .-v" : 

Página Web 
vele;artículos; 
cÓmpTados;; 

iGliente,; 

El cliente realiza 
el pedido 

Cliente 

Hacer che en el botón 
"Realizar pedido" 
de la página Web 

Desplegar página Web 
del pedido del cliente. 

Página Web 
de verificación 


Obtener .. 
pago del 
cliente 

Cliente 

. Información de tarjeta 
de crédito" ; ? ;:: 

•;••• C;- A *. : » r :: "S' ; 

- Verificar monto de la tarjeta ri^rí.‘A~ i^ +-,«„+- R . 

de ered ittí ctíñ:;já';Góm pa ñ la¡"% □ecreaiio, 

::**aLÍé:emire r í’a A xáneÜv-¡.ll£B§foaíjtTÍeritáeiór ¡' 
tnviar. |S::dei:cliente¿/r¿¿ / >- . 

i::": '"i :i!i..''y ".i::. < y""- yv 'v; 

;Compáñíaque:: 
emite la tarjeta 
de crédito. 
Cliente 

Enviar correo 

electrónico 

al cliente 


Temporal, por horas 

Enviar correo electrónico 
al cliente para confirmar 
el envío. 


Cliente 
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deben almacenar en un archivo. Los elementos que no se teclean sino que son resultado de 
un cálculo o de una operación lógica se conocen como elementos derivados. 

A veces no queda claro cuántos procesos se deben colocar en un diagrama y cuándo 
crear un diagrama hijo. Una sugerencia es examinar cada proceso y contar el número de flu¬ 
jos de datos que entran y salen de él. Si el total es mayor que cuatro, el proceso es un buen 
candidato para un diagrama hijo. Los diagramas de flujo de datos físicos se ilustran más ade¬ 
lante en este capítulo. 


Modelación de eventos y diagramas de flujo de datos Un enfoque práctico para crear dia¬ 
gramas de flujo de datos físicos es elaborar un fragmento sencillo de un diagrama de flujo de 
datos para cada evento único del sistema. Los eventos propician que el sistema realice alguna 
actividad y actúan como detonadores del sistema. Un ejemplo de evento es el de un cliente 
que reserva un vuelo en la Web. Cada vez que se envía un formulario Web, se activan pro¬ 
cesos, como validar y almacenar los datos, y dar formato y desplegar la siguiente página. 

Por lo general, los eventos se sintetizan en una tabla de respuestas de eventos. En la fi¬ 
gura 7.12 se ilustra un ejemplo de una tabla de este tipo para una tienda virtual en Internet. 
Un fragmento de un diagrama de flujo de datos se representa mediante una fila de la tabla. 
Cada fragmento de DFD constituye un solo proceso de un diagrama de flujo de datos. A 
continuación, todos los fragmentos se combinan para formar el Diagrama. Las columnas del 
detonador y la respuesta se convierten en los flujos de datos de entrada y salida, y la actividad 
se transforma en el proceso. El analista debe determinar los almacenes de datos requeridos 
por el proceso examinando los flujos de datos de entrada y salida. La figura 7.13 ilustra una 
parte del diagrama de flujo de datos para las tres primeras columnas de la tabla de respues¬ 
ta de eventos. 



Diagramas de flujo de datos para 


las primeras tres filas de la tabla 


de eventos de respuesta de la 


tienda virtual en Internet. 





Tasas .de envíos 


Tablas de envío 


Registro de artículo 


Archivo maestro 
de artículos 


Artículo comprado 


Agregar 
artículo 
del cliente 


Página Web de 
artículo comprado 


Cliente 


Detalle del pedido 


Detalle del pedido 


Registro del cliente 


Archivo maestro 


de clientes 
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Un formulario de caso de uso 
para la tienda virtual en Internet 
describe la actividad Agregar 
articulo del cliente y sus . 
detonadores, entrada y salida. 


La ventaja de construir diagramas de flujo de datos con base en eventos es que los usua¬ 
rios conocen los eventos que se llevan a cabo en sus áreas de negocios y saben de qué manera 
impulsan otras actividades los eventos. 


Casos de uso y diagramas de flujo de datos En el capítulo 18 presentaremos el concepto 
de caso de uso proveniente del Lenguaje Unificado de Modelación (UMLJ. Podemos usar 
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esta noción de caso de uso para crear diagramas de flujo de datos. Un caso de uso sintetiza 
un evento y tiene un formato similar para las especificaciones de un proceso (que se descri¬ 
ben en el capítulo 9]. Cada caso de uso define una actividad y su detonador, entrada y sali¬ 
da. La figura 7.14 ilustra un caso de uso para el proceso 3, Agregar artículo del cliente. 

Este enfoque permite al analista trabajar con los usuarios para comprender la naturale¬ 
za de los procesos y las actividades y crear a continuación un solo fragmento de diagrama de 
flujo de datos. Al crear casos de uso, primero realice un intento inicial por definir los casos 
de uso sin entrar en detalles. Este paso ofrece un panorama global del sistema y conduce a 
la creación del Diagrama 0. Decida cuáles deben ser los nombres y proporcione una breve 
descripción de la actividad. Liste las actividades, entradas y salidas de cada uno. 

Asegúrese de documentar los pasos que realice en cada caso de uso. Estos deben tener 
la forma de reglas de negocios que listen o expliquen las actividades realizadas para cada 
caso de uso. De ser posible, lístelas en la secuencia en que se ejecutarían normalmente. A 
continuación, determine los datos utilizados en cada paso. Este paso es más sencillo si se ha 
elaborado un diccionario de datos. Por último, pida a los usuarios que revisen los casos de 
uso y sugieran modificaciones a los mismos. Es importante que los casos de uso se escriban 
con claridad. 


PARTI C10NAMIENT0 DE LOS DIAGRAMAS DE FLUJO DE DATOS 

El particionamiento es el proceso de examinar un diagrama de flujo de datos y determinar 
cómo se debe dividir en colecciones de procedimientos manuales y colecciones de pro¬ 
gramas de cómputo. Analice cada proceso para determinar si debe ser un proceso manual o 
automatizado. Agrupe los procedimientos automatizados en una serie de programas de 
cómputo. A menudo se traza una línea punteada alrededor de un proceso o grupo de proce¬ 
sos que deben colocarse en un solo programa de cómputo. 

Existen seis razones para particionar diagramas de flujo de datos: 

1. Diferentes grupos de usuarios. ¿Los procesos son realizados por varios grupos de usuarios 
diferentes, con frecuencia en distintas ubicaciones físicas de la compañía? Si es así, se 
deben particionar en diferentes programas de cómputo. Un ejemplo es la necesidad de 
procesar devoluciones de los clientes y pagos de los clientes en un almacén de departa¬ 
mentos. Ambos procesos implican obtener información financiera que se utiliza para 
ajustar las cuentas de los clientes (restando de la cantidad las deudas de los clientes), 
pero son ejecutados por diferentes grupos de usuarios en distintas ubicaciones. Cada 
grupo requiere una pantalla diferente para registrar los detalles de la transacción, ya sea 
una pantalla de crédito o una de pago. 

2. Sincronización. Examine la sincronización de los procesos. Si dos procesos se realizan en 
diferentes momentos, no se pueden agrupar en un programa. Los aspectos de la sincro¬ 
nización también podrían involucrar qué cantidad de datos se presenta en un periodo 
determinado en una página Web. Si un sitio de comercio electrónico contiene páginas 
Web demasido pesadas para pedir artículos o reservar vuelos en línea, la página Web se 
podría particionar en programas separados que den formato a los datos y los presenten. 

3. Tareas similares. Si dos procesos ejecutan tareas similares, es posible agruparlos en un 
solo programa de cómputo. 

4. Eficiencia. En un programa se podrían combinar varios procesos para realizar un proce¬ 
samiento eficiente. Por ejemplo, si una serie de informes requieren utilizar los mismos 
archivos de entrada grandes, producirlos en conjunto podría ahorrar una cantidad con¬ 
siderable de tiempo de ejecución de la computadora. 

5. Consistencia de los datos. Los procesos se podrían combinar en un solo programa para 
mantener la consistencia de los datos. Por ejemplo, una compañía de tarjetas de crédito 
podría requerir un análisis de los datos en un punto en el tiempo, por lo que obtendría 
una imagen de los datos para producir una diversidad de informes al mismo tiempo con 
el fin de que las cifras sean consistentes. 

6. Seguridad. Los procesos se podrían particionar en diferentes programas por razones 
de seguridad. Se podría colocar una línea punteada alrededor de las páginas Web que se 
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encuentren en un servidor seguro para separarlas de las que estén en un servidor no se¬ 
guro. Por lo general, una página Web que se utiliza con el propósito de recabar la iden¬ 
tificación y la contraseña del usuario se particiona de las páginas de entrada de datos o 
de otras páginas de negocios. 

EJEMPLO DE UN DIAGRAMA DE FLUJO DE DATOS 

La corporación de nuestro ejemplo es FilmMagic, una cadena de renta de vídeos fundada 
por tres personas con experiencia en el negocio de la renta de vídeos. En la figura 7.15 se 
ilustra un resumen de las actividades de negocios obtenido de entrevistas realizadas a los 
propietarios de FilmMagic. El plan es contar con una serie de tiendas distribuidas estratégi¬ 
camente alrededor de un área metropolitana. La compañía también ha adoptado la singular 
política de otorgar rentas gratuitas de DVDs o juegos a los clientes que renten cantidades 
considerables de vídeos, en un intento por conseguir una buena participación de mercado. 
Según uno de los propietarios de la compañía: "Si las aerolíneas tienen programas de viajeros 
frecuentes, nuestras tienda de vídeos pueden contar con un programa de rentas recurrentes". 
En consecuencia, un programa de bonos mensuales para los clientes será parte del sistema. 



Empiece por crear una lista 
de actividades del negocio, que 
le servirán para identificar 
procesos, entidades externas 
y flujos de datos. 
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Diagrama de contexto de las 
¡ . tiendas de videos FilmMagic 


CREACIÓN DEL DIAGRAMA DE CONTEXTO 

En la figura 7.16 se muestra un diagrama de flujo de datos de contexto, que representa un 
panorama general de todo el sistema. Debido a que el sistema debe dar seguimiento a la 
cantidad de D VDs que haya rentado un cliente, la mayor parte del flujo de datos entra y sa¬ 
le de la entidad externa CLIENTE. 


DIBUJO DEL DIAGRAMA 0 

El Diagrama 0, que se muestra en la figura 7.17, ilustra las principales actividades del sis¬ 
tema de renta de vídeos de FilmMagic. Observe que hay un proceso para cada actividad 
principal. Cada proceso se analiza para determinar los datos requeridos y la salida produ¬ 
cida. El proceso 1, RENTAR ARTÍCULOS DE VÍDEO, resume la función principal del 
sistema, y es, por lo tanto, un proceso complejo. Observe los diversos flujos de datos de en¬ 
trada y salida. 

Para dibujar de manera correcta el diagrama de flujo de datos, se deben realizar pregun¬ 
tas como: "¿Qué información se necesita para rentar un DVD?" El CLIENTE requiere un 
ARTÍCULO DE RENTA DE VÍDEO (que podría ser un DVD o un juego de vídeo), un PA¬ 
GO y un ID DEL CLIENTE [una tarjeta para rentar). El ARTÍCULO DE RENTA DE 
VÍDEO se utiliza para buscar información correspondiente al DVD, como el precio y la 
descripción. El proceso crea una TRANSACCION EN EFECTIVO, que posteriormente ge¬ 
nera información sobre el EFECTIVO TOTAL RECIBIDO. El REGISTRO DEL CLIENTE 
se obtiene y actualiza con el importe total de la renta. Una flecha con doble punta indica 
que el REGISTRO DEL CLIENTE se obtiene y remplaza en la misma ubicación de archi¬ 
vo. El RECIBO DE LA RENTA y el DVD se entregan al CLIENTE. La INFORMACIÓN 
SOBRE LA RENTA, como la fecha y el artículo rentado, se produce para usarla más tarde 
en la ELABORACIÓN DE INFORMES PARA LA ADMINISTRACIÓN. 

Los demás procesos son más sencillos, con pocas entradas y salidas. El proceso 3, RE¬ 
GISTRAR VÍDEO DEVUELTO POR EL CLIENTE, actualiza el almacén de datos CLIEN¬ 
TE para reflejar que ya no hay artículos en renta. Se deben agregar nuevos clientes al almacén 
de datos CLIENTE para que se pueda rentar otro DVD. El proceso 5, AGREGAR NUEVO 
CLIENTE, toma INFORMACIÓN SOBRE CLIENTES NUEVOS y otorga al cliente una 
TARIETA PARA RENTAR VÍDEOS. El cliente debe presentar su tarjeta siempre que desee 
rentar un DVD. 
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Los procesos 2 y 4 producen información útil para administrar el negocio y tomar de¬ 
cisiones, como en qué momento reducir el precio de los DVDs que tengan mayor demanda 
y cuándo iniciar una campaña de publicidad para atraer clientes e incrementar, en conse¬ 
cuencia, el flujo de efectivo. Los procesos 6 y 7 utilizan la información del almacén de da¬ 
tos CLIENTE para ELABORAR CARTAS DE BONOS MENSUALES y ANUALES para el 
cliente. Observe que los nombres de los flujos de datos que salen de los procesos son dife¬ 
rentes, lo cual indica que algo ha transformado los datos de entrada para producir datos de 
salida. Todos los procesos empiezan con un verbo, como RENTAR, ELABORAR, REVI¬ 
SAR, RESUMIR o AGREGAR. 
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CREACIÓN DE UN DIAGRAMA HIJO 

La figura 7.18 es el diagrama hijo del proceso 1, RENTAR ARTÍCULOS DE VÍDEO, en el 
ejemplo de FilmMagic. El flujo de datos de entrada INFORMACIÓN SOBRE EL VÍDEO 
se conecta sólo con el proceso OBTENER REGISTRO DEL VÍDEO. El origen de esta en¬ 
trada es un área en blanco del dibujo. Este flujo de interfaz incompleto coincide con el flu¬ 
jo del proceso 1 del Diagrama 0. Lo mismo ocurre en el caso de ARTÍCULO DE RENTA 
DE VÍDEO, PAGO e ID DEL CLIENTE. 

El REGISTRO DEL CLIENTE también es un flujo de datos de interfaz, pero en el 
Diagrama 1 se conecta con el almacén de datos CLIENTE porque los almacenes de datos 
del diagrama padre también se pueden incluir en el diagrama hijo. Los flujos de datos de sa¬ 
lida TRANSACCIÓN EN EFECTIVO y RECIBO DE LA RENTA son flujos de interfaz 
que coinciden con la salida del proceso padre. El flujo NO SE ENCONTRARON ERRO¬ 
RES no se ilustra en el proceso padre porque una línea de error se considera como una sali¬ 
da menor. 

Los procesos de los diagramas hijos son más detallados, e ilustran la lógica requerida pa¬ 
ra producir la salida. El proceso OBTENER REGISTRO DEL VÍDEO utiliza RENTA DEL 
VÍDEO, que indica cuál DVD desea rentar el cliente, para buscar la INFORMACIÓN SO¬ 
BRE EL VÍDEO correspondiente (título, precio, etc.). El proceso 1.5, BUSCAR REGIS¬ 
TRO DEL CLIENTE, utiliza la ID DEL CLIENTE de la tarjeta para rentar vídeos con el 
propósito de localizar el registro del CLIENTE. El NOMBRE Y DIRECCIÓN DEL 
CLIENTE se imprime en el RECIBO DE LA RENTA que se deriva del proceso 1.4. 
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La figura 7.19 es el diagrama de flujo de datos físico que corresponde al Diagrama 0 lógico 
de FilmMagic. Los nombres de los flujos de datos se han cambiado para reflejar la imple- 
mentación. Ahora, el cliente proporciona un CÓDIGO DE BARRAS PARA LA RENTA 
DEL VÍDEO y un CÓDIGO DE BARRAS PARA LA ID DEL CLIENTE para el proceso 1, 
RENTAR ARTÍCULOS DE VÍDEO. La entidad SISTEMA DE COMPRA DE VÍDEOS se 
ha remplazado con un ARCHIVO MAESTRO DE VÍDEOS porque los archivos se utilizan 
para comunicarse entre sistemas. Ahora hay dos archivos de transacciones. El ARCHIVO 
DE TRANSACCIONES DE RENTA se utiliza para almacenar información desde el mo¬ 
mento que se rentan los vídeos hasta el momento en que son devueltos. El archivo de 
TRANSACCIONES EN EFECTIVO es necesario porque los vídeos se rentan durante todo 
el día, pero el INFORME SOBRE EL EFECTIVO RECIBIDO se elabora sólo una vez a la 
semana. Los datos se introducen mediante la PANTALLA DEL VÍDEO DEVUELTO (y los 
cargos por entregas atrasadas se calculan en el proceso 3, REGISTRAR VÍDEO DEVUELTO 
POR EL CLIENTE). Los clientes nuevos contestan el FORMULARIO PARA CLIENTES 
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NUEVOS, en tanto que en el diagrama de flujo de datos lógico este paso se denominaba 
simplemente INFORMACIÓN SOBRE CLIENTES NUEVOS. 

El Diagrama 1 del ejemplo de FilmMagic, que se ilustra en la figura 7.20, es un ejemplo 
de diagrama de flujo de datos físico hijo. Observe que hay procesos para escanear códigos de 
barras, desplegar pantallas, localizar registros, y crear y actualizar archivos. La secuencia 
de actividades es importante aquí, porque el énfasis se centra en la manera en que funcio¬ 
nará el sistema y en qué orden ocurrirán eventos. 
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La figura 7.21 ilustra el particionamiento del diagrama de flujo de datos físico de FilmMa- 
gic. Observe las líneas punteadas, que indican cuáles procesos deben estar en programas se¬ 
parados. El proceso RENTAR ARTÍCULOS DE VÍDEO funciona sobre una base minuto a 
minuto. El proceso REVISAR VÍDEO DEVUELTO POR EL CLIENTE también funciona 
en una base minuto a minuto. No obstante, las devoluciones se manejan posteriormente al 
proceso de renta, y por lo tanto ambos procesos deben colocarse en programas separados. 
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El proceso ELABORAR INFORME DEL EFECTIVO RECIBIDO se hace semanal¬ 
mente y por ende también debe colocarse en un programa aparte. Debido a que tanto el 
REGISTRO DE TRANSACCIONES EN EFECTIVO que entra a este proceso como el IN¬ 
FORME DEL EFECTIVO RECIBIDO que sale del proceso constituyen información de 
computadora, el proceso se debe implementar como programa en lotes. Lo mismo se aplica 
al proceso 4, ELABORAR INFORMES PARA LA ADMINISTRACIÓN; al proceso 6, 
ELABORAR CARTA DEL BONO MENSUAL, y al proceso 7, ELABORAR CARTA DEL 
BONO ANUAL. 

El proceso 5, AGREGAR CLIENTE NUEVO, se puede implementar en lotes o en lí¬ 
nea. Puesto que es probable que el cliente espere la tarjeta de renta de vídeos al otro lado de 
una caja, un proceso en línea podría ofrecer el mejor servicio al cliente. 


SEGUNDO EJEMPLO DE UN DIAGRAMA DE FLUJO DE DATOS 

Con frecuencia, el primer contacto que tiene una persona con los diagramas de flujo de da¬ 
tos ocasiona confusión por la gran cantidad de conceptos y definiciones nuevos. El siguiente 
ejemplo tiene el propósito de ilustrar el desarrollo de un diagrama de flujo de datos a través 
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de un examen selectivo de cada uno de los componentes que se han visto en este capítulo. 
El ejemplo, denominado "División de Catálogos de World's Trend" también se utilizará para 
ilustrar conceptos de los capítulos 8 y 9. 

En la figura 7.22 se puede observar la lista de actividades del negocio de World's Trend. 
Usted podría desarrollar esta lista con información recopilada mediante entrevistas, investi¬ 
gación y observación. La lista se puede utilizar para identificar entidades externas como 
CLIENTE, CONTABILIDAD y ALMACÉN, así como flujos de datos como INFORME DE 
CUENTAS POR COBRAR y ESTADO DE FACTURACIÓN DEL CLIENTE. Posterior¬ 
mente (al desarrollar los diagramas de nivel 0 y los diagramas hijos), la lista se puede em¬ 
plear para definir procesos, flujos de datos y almacenes de datos. 

Una vez que se desarrolla esta lista de actividades, elabore un diagrama de flujo de 
datos de contexto, como se ilustra en la figura 7.23. Este diagrama exhibe, al centro, el SIS¬ 
TEMA DE PROCESAMIENTO DE PEDIDOS (en el diagrama de contexto no se descri¬ 
ben procesos de manera detallada) y cinco entidades externas (en realidad, las dos entidades 
externas CLIENTE son una sola). También se muestran los flujos de datos que provienen de 
las entidades externas y van a éstas (por ejemplo, PEDIDO DEL CLIENTE y LISTA DE 
SELECCIÓN DE PEDIDOS). 

A continuación, regrese a la lista de actividades y elabore una nueva lista de tantos pro¬ 
cesos y almacenes de datos como pueda encontrar. Más tarde puede agregar los que quiera, 
pero empiece ahora a elaborar la lista. Si considera que tiene suficiente información, dibuje 
un diagrama de nivel 0 como el de la figura 7.24. Déle el nombre de Diagrama 0 y mantenga 
el carácter general de los procesos con el fin de no complicar el diagrama. Posteriormente 
puede agregar detalles. Cuando termine de dibujar los siete procesos, dibuje flujos de datos 
entre ellos y las entidades externas (las mismas entidades externas que se mostraron en el 
diagrama de contexto). Si considera que hay necesidad de un almacén de datos externos 
como ARCHIVO MAESTRO DE ARTÍCULOS o ARCHIVO MAESTRO DE CLIENTES, 
dibújelos y conéctelos a los procesos utilizando flujos de datos. Ahora dedique tiempo a nu¬ 
merar los procesos y los almacenes de datos. Ponga especial cuidado en que los rótulos sean 
significativos. Busque errores y corríjalos antes de avanzar. 







Ahora intente dibujar un diagrama hijo (también conocido como diagrama de nivel 1) 
como el de la figura 7.25. Numere sus diagramas Diagrama 1, Diagrama 2, etc., de acuerdo 
con el número que le haya asignado a cada proceso en el diagrama de nivel 0. Cuando dibu¬ 
je el Diagrama 1, primero haga una lista de subprocesos. Un proceso como AGREGAR PE¬ 
DIDO DEL CLIENTE puede tener subprocesos (en este caso son siete). Conecte estos 
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subprocesos entre sí y con los almacenes de datos, según sea conveniente. Los subprocesos 
no tienen que conectarse a entidades externas, puesto que siempre nos podemos remitir al 
diagrama de flujo de datos padre (o de nivel 0) para identificar estas entidades. Numere los 
subprocesos como 1.1, 1.2, 1.3, etc. Dedique tiempo a buscar errores y asegúrese de que 
los rótulos sean significativos. 


Si desea ir más allá del modelo lógico y dibujar también un modelo físico, observe la fi¬ 
gura 7.26, que constituye un ejemplo de un diagrama de flujo de datos físico hijo del pro¬ 
ceso 3, ELABORAR LISTADOS DE SELECCIÓN. Cuando rotule un modelo físico, tenga 
cuidado de describir el proceso con gran detalle. Por ejemplo, el subproceso 3.3 de un mo¬ 
delo lógico se podría llamar simplemente CLASIFICAR ARTÍCULO PEDIDO, pero en el 
modelo físico sería mejor un nombre como CLASIFICAR ARTÍCULO PEDIDO POR 
UBICACIÓN DENTRO DEL CLIENTE. Cuando escriba el rótulo para un almacén de da- 











tos, tome como base el archivo o base de datos real, como ARCHIVO MAESTRO DE 
CLIENTES o ARCHIVO DE ARTÍCULOS PEDIDOS CLASIFICADOS. Cuando nombre 
flujos de datos, describa el formulario, informe o pantalla real. Por ejemplo, cuando impri¬ 
ma un listado para seleccionar pedidos, nombre al flujo de datos como LISTADO DE SE¬ 
LECCIÓN DE PEDIDOS. 

Por último, tome el diagrama de flujo de datos físico y sugiera el particionamiento 
mediante la combinación o separación de los procesos. Como ya se indicó, existen muchas 
razones para particionar: identificar distintos procesos para diferentes grupos de usuarios. 
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separar procesos que requieren realizarse en diferentes momentos, agrupar tareas similares, 
agrupar procesos en busca de eficiencia, combinar procesos por consistencia o separarlos 
por seguridad. La figura 7.27 muestra que el particionamiento es útil en el caso de la Divi¬ 
sión de Catálogos de World's Trend. Usted podría agrupar los procesos 1 y 2 porque suena 
lógico agregar nuevos clientes al mismo tiempo que hacen sus primeros pedidos. A conti¬ 
nuación, podría colocar los procesos 3 y 4 en dos particiones independientes. Aunque ambos 
son procesos por lotes, deben realizarse en diferentes momentos y por lo tanto no es posible 
agruparlos en un solo programa. 

Ahora el desarrollo de un diagrama de flujo de datos se realiza con un enfoque jerár¬ 
quico de arriba hacia abajo, dibujando en primer lugar un diagrama de flujo de datos físico 
en conjunto con el diagrama de flujo de datos lógico, y particionando el diagrama de flujo 
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de datos mediante la agrupación o separación los procesos. El ejemplo de World's Trend se 
utilizará nuevamente en los capítulos 8 y 9. 


PARTIC10NAMIENTO DE SITIOS WEB 

El particionamiento constituye un principio muy útil al diseñar un sitio Web. Los diseña¬ 
dores de sitios Web que utilicen formularios para recopilar datos podrían obtener mejores 
resultados al dividir un sitio Web en una serie de páginas Web, ya que de esta manera incre¬ 
mentarían la velocidad de procesamiento y la facilidad de mantenimiento del sitio. Cada 
vez que deban obtenerse datos de un almacén de datos o un socio externo, el diseñador de 
un sitio Web podría considerar la creación de un formulario Web y un proceso DFD únicos 
para validar y procesar los datos. 

Un buen ejemplo de lo anterior se puede observar en el desarrollo de un sitio Web de 
reservaciones de viajes. Para simplificar, consideraremos únicamente la parte de reservación 
de vuelos del sitio Web, que se muestra en el diagrama de flujo de datos de la figura 7.28. 
Observe que el diseñador Web ha elegido crear varios procesos y particiones únicas para ha¬ 
cer una reservación de vuelo. El proceso 1 recibe y valida las fechas y aeropuertos que intro¬ 
duce el cliente [o el agente de viajes que representa al cliente). Los datos seleccionados se 
emplean para obtener detalles del vuelo y crear un almacén de datos de transacciones de los 
detalles del vuelo que coincidan con la solicitud de vuelo. 

Es recomendable particionar el proceso de búsqueda de la información de vuelo como 
un proceso separado, porque los detalles deben buscarse en un almacén de datos y se utili¬ 
zarán para desplegar una serie de páginas Web sucesivas con los vuelos que coincidan. A 
continuación, una vez que un cliente elija un vuelo, la información debe enviarse a una 
aerolínea seleccionada. Es importante que el archivo de transacciones de DETALLES DE 
VUELO esté disponible para desplegar cada página Web de nuevos vuelos porque realizar 
cada vez la búsqueda podría consumir una gran cantidad de tiempo. 

La selección de vuelos disponibles [proceso 2) utiliza una base de datos interna, pero 
esta última no cuenta con información acerca de la disponibilidad de asientos, porque las 
aerolíneas reciben reservaciones de muchas organizaciones de servicios de viajes. Esto im¬ 
plica que debe haber un proceso separado y un pequeño programa particionado para deter¬ 
minar si hay asientos disponibles y reservar asientos específicos. 

Dado que los usuarios deben introducir muchos datos, se diseñan formularios para ma¬ 
nejar todas sus solicitudes. Al contar con formularios separados, éstos son menos complejos 
y en consecuencia más atractivos para los usuarios ya que pueden completarlos con más fa¬ 
cilidad. Esto también implica que el procesamiento será más rápido porque una vez que se 
elija un vuelo, el siguiente paso, consistente en la elección de asientos, no requerirá que el 
usuario ingrese o incluso vea nuevamente los detalles de vuelo. Air France emplea ventanas 
emergentes (pop-up Windows], en las cuales los clientes pueden elegir sus asientos apuntan¬ 
do con el ratón. 

Otra razón para el particionamiento es garantizar la seguridad de la transacción. Una 
vez que selecciona el asiento, el cliente debe confirmar la reservación y proporcionar la in¬ 
formación de su tarjeta de crédito. Esto se hace mediante una conexión segura, y la compa¬ 
ñía que emite la tarjeta de crédito tiene que autorizar la cantidad de la compra. La conexión 
segura implica que debe utilizarse un proceso separado. Después de que se confirma la tar¬ 
jeta de crédito, es necesario incluir dos procesos adicionales, uno para dar formato a una 
confirmación y a un boleto electrónico y enviarlos al cliente a través de correo electrónico, 
y otro para enviar una notificación de la compra del vuelo a la aerolínea. 

Todo el procedimiento debe particionarse en una serie de procesos que interactúan 
entre sí, cada uno con su correspondiente página Web o interacción con un sistema externo. 
Cada vez que se utiliza un nuevo almacén de datos para obtener datos adicionales, debe in¬ 
cluirse un proceso para dar formato a los datos u obtenerlos. Siempre que se involucren 
una compañía o sistema externos, debe particionarse un proceso en un programa separado. 
La tarea de modificar procesos o formularios no es significativa. El reducido tamaño de los 
programas facilita los cambios. De esta manera, el sitio Web es seguro, eficiente y fácil de 
mantener. 
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COMUNICACION MEDIANTE DIAGRAMAS DE FLUJO DE DATOS 

Los diagramas de flujo de datos son útiles durante todo el proceso de análisis y diseño. Utilice 
diagramas de flujo de datos originales, sin ampliar, en las primeras etapas de la determina¬ 
ción de requerimientos de información. En esta fase ayudarán a conseguir un panorama ge¬ 
neral del movimiento de los datos a través del sistema, ofreciendo una perspectiva visual 
que no se puede lograr con los datos recopilados en forma oral. 
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NO HAY UN NEGOCIO IGUAL AL QUE FLUYE 


El teléfono de Merman's Costume Rentáis suena, y Annie Oaklea, jefa 
de inventario de disfraces, lo descuelga y contesta así: "Permítame revi¬ 
sar mis tarjetas de inventario. Lo siento, al parecer en inventario sólo hay 
dos disfraces de oso macho, con gestos de fiereza muy acentuados. Te¬ 
nemos una gran demanda de osos. ¿Cuándo los necesita? Tal vez nos 
regresen uno. No, lo siento, no los tenemos. ¿Aún así le gustaría que le 
enviáramos estos dos? ¿Cuál es el nombre de su negocio? ¿Manhattan 
Theatre Company? ¿Sucursal en Londres? Correcto. ¡Excelente compa¬ 
ñía! Veo en nuestra tarjeta de cuentas que ustedes ya han rentado dis¬ 
fraces con nosotros. ¿Y por cuánto tiempo necesitará los disfraces?” 


La figura 7.CT es un diagrama de flujo de datos que establece las etapas 
para el procesamiento de renta de disfraces de Merman's. Refleja las rentas 
como la que Annie le está haciendo á la Manhattan Theatre Company. 

Después de conversar durante algunos momentos más sobre la polí¬ 
tica del establecimiento acerca de arreglos a los disfraces, Annie conclu¬ 
ye: "Tienen mucha suerte de haber conseguido los osos con tan poco 
tiempo de anticipación. Otra compañía los reservó para la primera se¬ 
mana de julio. Los pondré a ustedes en la lista de los disfraces de oso, y 
se los enviaremos directamente con nuestro mensajero. Como siempre, 
la devolución puntual nos ahorrará muchos problemas a todos”.. 
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Diagrama de flujo de datos para Merman's. Costume Rentáis. 
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USO DE DIAGRAMAS DE FLUJO DE DATOS 









La empresa de renta de disfraces Merman's se localiza en el mun¬ 
dialmente famoso distrito de teatros West End de Londres. Cuando un 
teatro o una compañía televisora carece de recursos (ya sea tiempo o co¬ 
nocimientos) para elaborar un disfraz por su cuenta, no se hace esperar 
el "¡Llamen a Merman's!" y éste procede a rentar lo que sea necesario 
sin tantos problemas. 

La tienda (con una apariencia más cercana a la de un almacén) se 
extiende por tres pisos repletos de estantes con disfraces, que contienen 
miles de disfraces clasificados por periodo histórico, por género y porta- 


lia. 1 La mayoría de las compañías de teatro localizan exactamente lo que 
necesitan con la eficaz ayuda de Annie. 

A continuación realice a la medida la parte devolución de rentas del 
diagrama de flujo de datos que se muestra en la figura 7.C1. Recuerde 
que las devoluciones puntuales de los disfraces rentados son cruciales 
para que Merman's mantenga la confianza de sus clientes. 

1 Se dice que la Western Costume Company de Hollywood, California, 
tiene más de un millón de disfraces con un valor de más de 40 millones 
de dólares. 


Un analista de sistemas podría ser bastante competente para bosquejar la lógica del 
flujo de datos para los diagramas de flujo de datos, pero para que los diagramas cumplan 
verdaderamente su función de comunicación, también se requieren rótulos que reflejen el 
significado de todos los componentes de datos. Los rótulos no deben ser genéricos, porque 
entonces no indicarán bien el propósito de la situación real. Todos los modelos de sistemas 
generales implican la configuración de entrada, procesos y salida, por ello los rótulos de un 
diagrama de flujo de datos tienen que ser más específicos. 

Por último, recuerde que los diagramas de flujo de datos se utilizan para documentar el 
sistema. Dé por sentado que los diagramas de flujo de datos permanecerán mucho más que 
la gente que los dibuja, lo cual, por supuesto, siempre es verdad si quien los dibuja es un 
consultor externo. Los diagramas de flujo de datos se pueden utilizar para documentar ni¬ 
veles altos o bajos de análisis y ayudar a sustentar la lógica subyacente en los flujos de datos 
de las organizaciones. 



RESUMEN 

Para entender mejor el movimiento lógico de los datos a través de una empresa, el analista 
de sistemas dibuja diagramas de flujo de datos (DFDs). Estos diagramas son herramientas 
estructuradas de análisis y diseño que permiten al analista comprender visualmente el siste¬ 
ma y los subsistemas como un conjunto de flujos de datos interrelacionados. 

Las representaciones gráficas del movimiento, almacenamiento y transformación de los 
datos, se dibujan mediante cuatro símbolos: un rectángulo redondeado para ilustrar el pro¬ 
cesamiento o transformaciones de datos, un cuadrado doble para mostrar una entidad de 
datos externa (origen o receptora de datos), una flecha para describir el flujo de datos y un 
rectángulo abierto para representar un almacén de datos. 

El analista de sistemas extrae procesos de datos, orígenes, almacenes y flujos de los pri¬ 
meros relatos de la organización y utiliza un enfoque jerárquico hacia abajo para dibujar 
primero un diagrama de flujo de datos de contexto del sistema a un nivel muy general. A 
continuación dibuja un diagrama de flujo de datos lógico de nivel 0. Se muestran los proce¬ 
sos y se agregan almacenes de datos. En seguida, el analista crea un diagrama hijo para cada 
uno de los procesos del Diagrama 0. Las entradas y salidas permanecen constantes, pero los 
almacenes y los orígenes de datos cambian. La ampliación del diagrama de flujo de datos 
original permite al analista de sistemas enfocarse en descripciones cada vez más detalladas 
del movimiento de los datos en el sistema. El analista desarrolla entonces un diagrama de 
flujo de datos físico a partir del diagrama de flujo de datos lógico, y lo particiona para facili¬ 
tar la programación. Cada proceso se analiza para determinar si se trata de un procedimien¬ 
to manual o uno automatizado. 

Seis consideraciones para particionar diagramas de flujo de datos incluyen si los pro¬ 
cesos son realizados por diferentes grupos de usuarios, si se ejecutan al mismo tiempo, si de¬ 
sempeñan tareas similares, si se pueden combinar para realizar un procesamiento eficiente, 
si se pueden combinar en un programa para mantener la consistencia de los datos, o si se 
pueden particionar en diferentes programas por razones de seguridad. 
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"Su postura en relación con los problemas que tenemos aquí en MRE es muy interesante. 
Lo he visto bosquejando diagramas de nuestras operaciones casi desde el día en que pisó 
nuestras instalaciones por primera Vez. En realidad ya me acostumbré a verlo garabateando 
por todos lados. ¿Cómo los llamó? Ah, sí. Diagramas de contexto. ¿Y diagramas de flujo? 
Ah, no. Diagramas de flujo de datos. Así es, ¿verdad?". 



PREGUNTA DE HYPERCASE 

1. Busque los diagramas de flujo de datos que haya en MRE. Haga una lista con los que 
encuentre y agregue una columna para indicar en qué parte de la Organización los halló. 

2. Dibuje un diagrama de contexto que modele el proceso Desarrollo de proyectos de la 
Unidad de Capacitación, que se base en entrevistas de casos con el personal importante 
de la Unidad de Capacitación. A continuación dibuje un diagrama de nivel 0 que deta¬ 
lle el proceso. 
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En HyperCase usted puede hacer clic en los elementos de un diagrama de flujo de datos. 















equilibrio vertical 
flujo de datos de interfaz 
fragmento del diagrama de flujo 
de datos 

funcionalmente primitivo 
Lenguaje Unificado de Modelación 
(UML) 

modelación de eventos 
modelo físico 


modelo lógico 
particionamiento 
proceso de transformación 
proceso en línea 
proceso padre 
proceso primitivo 
sistema orientado a datos 
tabla de respuestas de eventos 


PREGUNTAS DE REPASO 

1. ¿Cuál es uno de los métodos principales que está disponible para que el analista lo use 
cuando analiza los sistemas orientados a datos? 

2. ¿Cuáles son las cuatro ventajas de usar un enfoque de flujo de datos sobre las explica¬ 
ciones narrativas del movimiento de datos? 

3. ¿Cuáles son los cuatro artículos de datos que se pueden simbolizar en un diagrama de 
flujo de datos? 

4. ¿Qué es un diagrama de flujo de datos de contexto? Compárelo con un DFD de nivel 0. 

5. Defina el enfoque "de arriba hacia abajo" así como su relación al dibujar los diagramas 
de flujo de datos. 

6. Describa lo que significa "dividir" diagramas de flujo de datos. 

7. ¿Cuáles son los pros y los contras involucrados para decidir hasta dónde se deben divi¬ 
dir los flujos de datos? 

8. ¿Por qué es tan importante etiquetar los diagramas de flujo de datos? ¿Qué etiquetas se 
pueden implementar eficazmente en los diagramas de flujo de datos para aquellos que 
no están familiarizados con el sistema? 

9. ¿Cuál es la diferencia entre un diagrama de flujo de datos lógico y uno físico? 

10. Mencione tres razones para crear un diagrama de flujo de datos lógico. 

11. Mencione cinco características encontradas en un diagrama de flujo de datos físico que 
un diagrama de flujo de datos lógico no tiene. 

12. ¿Cuándo se requieren los archivos de transacción en el diseño del sistema? 

13. ¿Cómo se puede usar una tabla de eventos para crear un diagrama de flujo de datos? 

14. Mencione las secciones principales de un caso de uso. 

15. ¿Cómo se puede usar un caso de uso para crear un diagrama de flujo de datos? 

16. ¿Qué es el particionamiento y cómo se usa? 

17. ¿Cómo puede determinar un analista cuándo se requiere una interfaz de usuario? 

18. Mencione tres formas de determinar el particionamiento en un diagrama de flujo de 
datos. 

19. Mencione tres formas de usar diagramas de flujo de datos terminados. 


PROBLEMAS 

1. En dos párrafos, defienda el argumento siguiente: "Una ventaja de los diagramas de flu¬ 
jo de datos lógicos es que libran al analista de sistemas del compromiso prematuro de 
la implementación técnica del sistema". Use un ejemplo para apoyar lo que escribe. 

2. Hasta ahora parece que ha tenido una excelente relación con Kathy Kline, uno de los 
gerentes que usarán el sistema que usted propone. Sin embargo, cuando le haya mostra¬ 
do los diagramas de flujo de datos que usted dibujó, no los entenderá. 

a. En un párrafo, apunte en términos generales, cómo explicar a un usuario qué es 
un diagrama de flujo de datos. Asegúrese de incluir una lista de símbolos y su sig¬ 
nificado. 

b. Se necesita un esfuerzo para enseñar a los usuarios sobre los diagramas de flujo de 
datos. ¿Vale la pena compartirlos con los usuarios? ¿Por qué sí o por qué no? De¬ 
fienda su respuesta en un párrafo. 


EL PROCESO DE ANÁLISIS 






3. Una experiencia común que los estudiantes en cada universidad comparten es matricu¬ 
larse en un curso. 

a. Dibuje un diagrama de flujo de datos de nivel 1 del movimiento de los datos para 
matricularse en un curso de la universidad. Use una sola hoja y etiquete claramen¬ 
te cada elemento de datos. 

b. Amplíe uno de los procesos de su diagrama de flujo de datos original en subproce¬ 
sos, agregando flujos de datos y almacenes de datos. 

c. Mencione las partes del proceso de la matriculación que están "ocultas" al observa¬ 
dor externo y a las cuales ha tenido que hacer suposiciones para completar un dia¬ 
grama de nivel inferior. 

4. La figura 7.EX1 es un diagrama de flujo de datos de nivel 1 del movimiento de los da¬ 
tos en una agencia de turismo en las Cataratas del Niágara llamada Marilyn's Tours. 
Léalo brevemente, verificando cualquier inexactitud. 

a. Mencione y numere los errores que ha encontrado en el diagrama. 

b. Vuelva a dibujar y etiquetar el diagrama de flujo de datos de Marilyn's de manera 
que sea correcto. Asegúrese de que su nuevo diagrama emplea los símbolos ade¬ 
cuadamente para consumir menos repeticiones y duplicaciones donde sea posible. 

5. Perfect Pizza necesita instalar un sistema para registrar los pedidos de pizza y alitas de 
pollo. Cuando los clientes regulares llaman por teléfono a Perfect Pizza, se les pide su 
número telefónico. Cuando se teclea dicho número en una computadora, el nombre, la 
dirección y la última fecha de pedido aparecen automáticamente en la pantalla. Una 
vez que se toma el pedido, se calcula el total, incluyendo el impuesto y entrega. Des¬ 
pués se pasa el pedido al cocinero. Se imprime un recibo. De vez en cuando, se impri¬ 
men ofertas especiales [cupones) de manera que se le hace un descuento al cliente. Los 
choferes que hacen las entregas les dan a los clientes una copia del recibo y un cupón 
(si hay). Los totales se guardan semanalmente para la comparación con el desempeño 
del último año. Escriba un resumen de las actividades del negocio para tomar un pedi¬ 
do en Perfect Pizza. 

6. Dibuje un diagrama de flujo de datos de contexto para Perfect Pizza (problema 5). 

7. Amplíe el diagrama de contexto del problema 6 mostrando todos los procesos princi¬ 
pales. Llame a este diagrama 0. Debe ser un diagrama de flujo de datos lógico. 

8. Dibuje un diagrama lógico hijo para el diagrama 0 del problema 7 para el proceso que 
agrega a un nuevo cliente si no está actualmente en la base de datos (nunca ha pedido 
antes de la Perfect Pizza). 




Un diagrama de flujo de datos 
hecho a mano para Marilyn’s 
. Tours. 
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9. Dibuje un diagrama de flujo de datos físico para el problema 7. 

10. Dibuje un diagrama de flujo de datos físico para el problema 8. 

11. Particione el diagrama de flujo de datos físico del problema 7, agrupando y separando 
los procesos como considere apropiado. Explique por qué particiona el diagrama de 
flujo de datos de esta forma. (Recuerde que no debe particionar el diagrama entero, só¬ 
lo las partes que tengan sentido.) 

12. a. Dibuje un diagrama lógico hijo para el proceso 6 de la figura 7.24. 

b. Dibuje un diagrama físico hijo para el proceso 6 de la figura 7.24. 

13. Dibuje un diagrama de flujo de datos físico para el proceso 1.1 de la figura 7.25. 

14. Cree un diagrama de contexto para un agente inmobiliario que intenta crear un siste¬ 
ma que reúna a los compradores con las casas potenciales. 

15. Dibuje un diagrama de flujo de datos lógico que muestre los procesos generales para el 
problema 14. Llámelo diagrama 0. 

16. Cree un diagrama de contexto para facturar en un consultorio dental. Las entidades ex¬ 
ternas incluyen los pacientes y las compañías de seguros. 

17. Dibuje un diagrama de flujo de datos lógico que muestre los procesos generales para el 
problema 16. Llámelo diagrama 0. 

18. Cree un caso de uso para la lista de seis actividades para el sistema de renta de vídeos 
LilmMagic. Remítase a la figura 7.17 si fuera necesario. 

19. Cree una tabla de respuestas de eventos para las seis actividades del sistema de renta de 
vídeos de LilmMagic. 

20. Cree una tabla de respuestas de eventos para las actividades listadas por el sistema 
de procesamiento de pedidos del World's Trend. 

21. Cree un caso de uso para la lista de siete procesos para el sistema de procesamiento de 
pedidos del World's Trend. 

22. Cree una matriz CLAE para LilmMagic. 

23. Cree una matriz CLAE para los archivos del World's Trend. 

24. Use los principios de la partición para determinar qué procesos del problema 19 se de¬ 
ben incluir en programas separados. 

25. Cree un diagrama de flujo de datos físico hijo para la situación siguiente: el grupo de 
usuarios de PC local se reúne una vez por mes con los portavoces informativos, la puerta 
aprecia y sesiones para los grupos de interés especiales. Una computadora portátil se 
usa en las reuniones para agregar al grupo los nombres de nuevos miembros. El diagra¬ 
ma representa un proceso en línea y es el hijo del proceso 1, AGREGAR NUEVOS 
MIEMBROS. Se incluyen las tareas siguientes: 

a. Teclear la información del nuevo miembro. 

b. Validar la información. Los errores se despliegan en la pantalla. 

c. Cuando toda la información es válida, se despliega una pantalla de confirmación. 
El operador confirma visualmente que los datos son correctos y acepta la transac¬ 
ción o la cancela. 

d. Las transacciones aceptadas agregan a los nuevos miembros al ARCHIVO 
MAESTRO DE MEMBRESÍAS que se guarda en el disco duro de la computadora 
portátil. 

e. Las transacciones aceptadas se escriben en un archivo de BITÁCORA DE MEM¬ 
BRESÍAS que se guarda en un disco. 


PROYECTOS DE GRUPO 

1. Reúnase con su grupo para desarrollar un diagrama de flujo de datos de contexto para 
Maverick Transport (introducido en el capítulo 4). Use algunos datos sobre Maverick 
Transport que ha generado posteriormente con su grupo. [Pista: Concéntrese en una 
de las áreas funcionales de la compañía en lugar de intentar modelar la organización 
entera.) 

2. Usando el diagrama de contexto desarrollado en el problema 1, desarrolle con su grupo 
un diagrama de flujo de datos lógico de nivel 0 para Maverick Transport. Haga las supo¬ 
siciones necesarias para dibujarlo. Menciónelas. 
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3. Con su grupo, elija un proceso clave y divídalo en un diagrama lógico hijo. Haga las su¬ 
posiciones necesarias para dibujarlo. Prepare una lista de preguntas de seguimiento y 
sugiera otros métodos para obtener más información de los procesos que aún no le que¬ 
den claros. 

4. Use el trabajo que su grupo ha hecho hasta hoy para crear un diagrama de flujo de da¬ 
tos físico de una parte del nuevo sistema que usted está proponiendo para Maverick 
Transport. 
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Después que se recopilan y analizan los resultados de las entrevistas, cuestionarios y elabo¬ 
ración de prototipos, Anna y Chip continúan con el siguiente paso, modelar el sistema. Su 
estrategia es crear un conjunto en capas de diagramas de flujo de datos y después describir 
los componentes. 

El modelado inicia con el análisis del diagrama de contexto del sistema actual de inven¬ 
tario por computadora. Este diagrama es fácil de crear y es la base de los niveles siguientes 
porque describe las entidades externas y el flujo de datos principal. 

"¿Crearemos un diagrama de flujo de datos físico del sistema actual?", pregunta Chip. 

Anna contesta: "No, es bastante simple de entender y no obtendríamos ningún nuevo 
conocimiento significativo del funcionamiento del sistema. Empecemos por crear un mode¬ 
lo lógico del sistema actual". 

Los diagramas de flujo de datos lógicos se completan en unos cuantos días. Anna y Chip 
se reúnen por la tarde para repasar los diagramas y retroalimentarse mutuamente. "Estos se 
ven bien", comenta Chip. "Podemos ver claramente los eventos del negocio que incluye el 
sistema actual." 

Anna contesta: "Sí, tomemos los actuales diagramas de flujo de datos lógicos y agre¬ 
guemos todos los requerimientos y características deseadas del nuevo sistema. También 
podemos eliminar todas las características innecesarias que no se implementarán en el 
nuevo sistema". 

Anna toma el diagrama de contexto (mostrado en el capítulo 2) y agrega varios de los 
informes, consultas y otra información incluida en el nuevo sistema. En la figura E7.1 se 
muestra el diagrama de contexto terminado. Observe la gran cantidad de flujos de datos 
nuevos. El departamento de mantenimiento recibirá informes que actualmente no están 
disponibles. Por ejemplo, el informe INSTALLATION LISTING ayuda a automatizar la 
instalación de computadoras nuevas, y el informe SOFTWARE CROSS-REFERENCE RE- 
PORT destinado para uso administrativo muestra qué software se localiza en qué máquinas. 

Chip revisa el diagrama terminado y comenta: "Esto es más arte que ciencia. Parece que 
están incluidos todos los requerimientos del nuevo sistema. Pero es más complejo de lo 
que originalmente pensé que sería". 

Anna contesta: "Ampliémoslo para hacer el diagrama 0 para el nuevo sistema. Esto será 
un diagrama de flujo de datos lógico porque debemos enfocarnos en las necesidades del ne¬ 
gocio. Quizás sería mejor si trabajamos en equipo para este diagrama". 

Después de trabajar durante varias horas por la tarde y una buena parte de la mañana 
siguiente, terminan el diagrama, con algunos pequeños cambios. En las figuras E7.2 y E7.3 
se muestra el diagrama 0 terminado. Debido a que es un diagrama lógico, no muestra ope¬ 
raciones de tecleo o validación, como tampoco almacenes de datos temporales ni archivos 
de transacción. El tiempo no se toma en cuenta (un ejemplo es el proceso ADD NEW 
COMPUTER, en el cual da la impresión de que los pedidos están actualizados y los infor¬ 
mes se producen simultáneamente). 

"Finalmente se ve bien", piensa Chip. "Están todos los procesos, flujos de datos y alma¬ 
cenes de datos importantes. Y el diagrama en general no parece muy complicado." 

"Ayudó el poner todas las consultas en un subsistema y todos los informes en otro. ¿Re¬ 
cuerdas qué tan complejo era el diagrama original?", pregunta Anna. 
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Diagrama de flujo de datos de contexto del sistema propuesto. 


"Claro", contesta Chip. "Empecé a creer que estábamos haciendo demasiado a la vez 
con este sistema. Por lo menos ahora es más manejable. ¿Ahora que se ha terminado, cuál es 
el siguiente paso?" 

"Necesitamos decidir cómo implementar el diagrama de flujo de datos en una serie de 
pasos, que se muestran en el diagrama de flujo de datos físico", dice Amia. "Este diagrama 
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EPISODIO 


Chip y Amia deciden abreviar el diagrama de nivel O como diagrama 0. Los detalles se 
muestran en un diagrama hijo, el diagrama 2. Las entidades externas no aparecen en el dia¬ 
grama, porque sólo se muestran en el diagrama de contexto y en el diagrama 0, la amplia¬ 
ción del diagrama de contexto. 

"He estado trabajando en el diagrama 1, una ampliación del proceso 1, ADD SOFT¬ 
WARE RECORD. Quizás te gustaría revisar el resultado final", comenta Anna. 

"Claro", contesta Chip. "Revisaré que no haya omisiones y errores." 

En la figura E7.4 se muestra el diagrama 1. El mismo programa introduce y edita la 
nueva información del software. Los errores se informan en la pantalla y el operador los co¬ 
rrige. Después de corregir todos los errores, el operador tiene la oportunidad de verificar 
cuidadosamente los datos. Si son correctos, el operador presiona una tecla para aceptar los 
datos; de lo contrario la transacción se podría cancelar o corregir. 

Los datos confirmados se agregan al archivo SOFTWARE MASTER y se usan para 
crear un SOFTWARE LOG RECORD. Este registro contiene toda la información tecleada 
por la persona que registra la transacción, como la fecha, la hora y el ID de usuario. En el 
diagrama ADD SOFTWARE, este registro se usa para crear la lista SOFTWARE INSTA- 
LLATION LIST, así como también para proporcionar una copia de seguridad de todas las 
transacciones nuevas y un seguimiento de las entradas. 

Debido a que Chip y Anna están usando Visible Analyst para crear los diagramas de 
flujo de datos, todos los componentes del diagrama se podrían describir en el depósito de 
Visible Analyst. Chip empieza a trabajar en el diagrama de flujo de datos ADD COM¬ 
PUTER. 

En la figura E7.5 se muestra la descripción para el proceso 2.5, UPDATE PENDING 
COMPUTER ORDER. El área Label contiene el texto que aparece en el diagrama. La en¬ 
trada Process Description es una de las áreas de entrada más importantes. En el ejemplo 
mostrado. Chip delinea la lógica detallada para actualizar el archivo PENDING COMPU¬ 
TER ORDER. 

Anna describe el almacén de datos SOFTWARE MASTER, mostrado en la figura E7.6. 
Este almacén de datos tiene la estructura del registro almacenado en el SOFTWARE RE¬ 
CORD, el cual se indica en el área Composition. El área Notes contiene detalles de los ele¬ 
mentos del índice o campos clave y el tamaño aproximado del archivo en los registros. 

En la figura E7.7 se muestra el flujo de datos NEW COMPUTER FORM diseñado por 
Chip. El área Alias contiene el nombre de la pantalla de la computadora que se usará para 
teclear los datos del formulario. Este flujo de datos tiene el NEW COMPUTER FORM RE¬ 
CORD en su campo Composition. Este registro contiene los detalles, tal como las estructuras 
y elementos, que son los detalles del NEW COMPUTER FORM. El área Notes contiene 
algunos de los detalles sobre la manera como se representa el formulario en una pantalla. 

Toma tiempo teclear las descripciones para todos los objetos, pero una vez que se com¬ 
pletan las entradas. Visible Analyst proporcionará análisis del diseño. La característica 
Analyze proporciona varias características importantes para validar el diagrama de flujo de 
datos, los diagramas ampliados y las conexiones. 

Cuando se analiza un diagrama de flujo de datos específico, el informe resultante po¬ 
dría revelar que cualquiera de los siguientes errores de sintaxis de un diagrama de flujo de 
datos existe en ese DFD: 

1. El diagrama de flujo de datos debe tener por lo menos un proceso, y no debe tener 

objetos independientes o conectados entre sí. 

2. Un proceso debe recibir por lo menos un flujo de datos y crear por lo menos un 

flujo. No deben ocurrir procesos con todas las entradas o todas las salidas. 

3. Un almacén de datos debe estar conectado por lo menos con un proceso. 
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Diagrama 1: Sistema de cómputo propuesto. 
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4. Las entidades externas no se deben conectar entre sí. Aunque se comunican indepen¬ 
dientemente, dicha comunicación no es parte del sistema a diseñarse. 

Visible Analyst no muestra los errores siguientes ni verifica las normas establecidas por 
Chip y Anna para el proyecto: 

1. Los nombres de los flujos de datos que entran y salen de un proceso deben ser diferen¬ 
tes (con excepciones). 
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1 Enter a bnef description about the object. 


Pantalla de descripción del proceso, UPDATE PENDING COMPUTER ORDER. 


2. El flujo lineal (varios procesos con una sola entrada y salida] no es muy común. Excep¬ 
to en los procesos de nivel muy inferior, ésta es una señal de advertencia de que a algu¬ 
nos de los procesos podrían faltarles flujos de entrada o salida. 

3. Las entidades externas no se deben conectar directamente a almacenes de datos. Por 
ejemplo, [usted no debe permitir que los empleados husmeen el archivo EMPLOYEE 
MASTER1 

4. Los nombres de los procesos deben contener un verbo para describir el trabajo desem¬ 
peñado (con excepciones, como en el caso de INQUIRY SUBSYSTEM). Los nombres 
de los flujos de datos deben ser sustantivos. 

Chip y Amia usan Visible Analyst para verificar que la sintaxis del diagrama de flujo de 
datos sea correcta. En la figura E7.8 se muestra el informe del análisis. Observe que se da un 
mensaje de error descriptivo para cada error, indicando entre comillas el objeto del diagra¬ 
ma relacionado con el problema. Este informe de errores se generó debido a los errores sin¬ 
tácticos en el diagrama de flujo de datos mostrado en la figura E7.9. 
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Pantana de descripción del almacén de dalos, SOFTWARE MASTER. 


Visible Analyst también verificará el equilibrio de los niveles entre los procesos del dia¬ 
grama de flujo de datos y los diagramas hijos. Se muestran las entradas y salidas que no coin¬ 
ciden. 


EJERCICIOS 



Use Visible Analyst para ver el diagrama de contexto para el sistema de cómputo 
propuesto. Experimente con los controles de Zoom en la barra de herramientas infe¬ 
rior para cambiar de una vista global a una detallada del diagrama. Haga doble clic en 
el proceso central para examinar su entrada en el depósito. Haga clic en el botón Exit 
para volver al diagrama. Haga clic con el botón derecho del ratón en el proceso cen¬ 
tral para desplegar el menú de objetos de este proceso. Use la opción Explode para 
desplegar el diagrama 0, que representa los detalles del proceso central. Maximice la 


¡ j ¡ | Los ejercicios precedidos por un ¡cono Web indican que en el sitio Web de este libro se dispone de mate¬ 
rial de valor agregado. 
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F4J.TÉR FORM 


ventana y haga doble clic en alguno de los almacenes de datos y flujos de datos para 
examinar sus entradas en el depósito. Haga doble clic en el botón Exit para regresar 
al diagrama. Ponga el Zoom al 100 por ciento y recorra la pantalla para ver diferen¬ 
tes partes del diagrama; después imprima el diagrama a lo ancho de la página. Haga 
clic en FILE, NEST y PARENT para regresar al diagrama de contexto. Maximice la 
ventana. 

E-2. Modifique el diagrama 0 del sistema de cómputo propuesto. Agregue el proceso 10, 
UPDATE SOFTWARE RECORD. Tendrá que colocar la entidad externa MANA¬ 
GEMENT más abajo en el diagrama; póngala a la izquierda del proceso 7, IN- 
QUIRY SUBSYSTEM. Cree una entrada en el depósito para el proceso y después 
haga clic en el botón Exit para volver al diagrama. Imprima el diagrama a lo ancho 
de la hoja. 

Entrada; 1. SOFTWARE CHANGE DATA, de CLERICAL SUPPORT 
2. SOFTWARE DELETE ID, de MANAGEMENT 
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Salida: 1 SOFTWARE RECORD, una actualización del almacén de datos 

SOFTWARE MASTER 


E-3. Expanda el diagrama 10, UPDATE SOFTWARE RECORD. Maximice la ventana y 
cree el diagrama que se ilustra en la figura E7.10. Conéctelo con el SOFTWARE 
MASTER mediante una flecha de doble punta. [Sugerencia: Haga clic con el botón 
derecho del ratón en el flujo de datos, seleccione Change ítem, después Change Type 
y Terminator Type, Double Filled.} Imprima el diagrama final. 

E-4. Modifique el diagrama 8, INSTALL SOFTWARE. Agregue los procesos siguientes, 
describiendo cada uno en el depósito. Ponga el Zoom al 100 por ciento y desplácese 
por la pantalla, y asegúrese de que su diagrama tenga una apariencia profesional. Im¬ 
prima el resultado final. 


Proceso: 

Descripción: 

Entrada: 

Salida: 

Proceso: 

Descripción: 

Entrada: 

Salida: 


8.2 INSTALL COMPUTER SOFTWARE 
Proceso manual, coloque el software en la máquina 

1. COMPUTER LOCATION, del proceso 8.1 

2. SOFTWARE TITLE AND VERSIÓN, del proceso 8.1 

l INSTALLED SOFTWARE FORM 

8.3 CRÉATE INSTALLED SOFTWARE TRANSACTION 
Proceso de entrada de datos por lote para crear transac¬ 
ciones de software instalado, incluyendo validación 

1. INSTALLED SOFTWARE FORM 

1, INSTALLED SOFTWARE TRANSACTION, para el 

almacén de datos INSTALLED SOFTWARE 
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Diagrama de flujo de datos con errores. 


Proceso: 


8.4 UPDATE SOFTWARE MASTER 

Descripción: 


Actualización aleatoria del almacén de datos 

SOFTWARE MASTER con información actualizada 

Entrada: 

1 . 

INSTALLED SOFTWARE TRANSACTION 

Salida: 

1 . 

SOFTWARE MASTER, actualizar 

Proceso: 


8.5 PRODUCE INSTALLATION NOTIFICARON 

Descripción: 


Produce una notificación de la instalación que informa a 
los usuarios en qué máquinas se ha instalado el software 

Entrada: 

1 . 

INSTALLED SOFTWARE TRANSACTION 


2. 

SOFTWARE MASTER, del almacén de datos 

SOFTWARE MASTER 
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Diagrama de flujo de datos, UPDATE SOFTWARE RECORD. 



3. HARDWARE MASTER, del almacén de datos 
COMPUTER MASTER 

Salida: 1. INSTALLATION NOT1FICATION LISTING, un flujo 

de interfaz 

||| E-5. Modifique el diagrama 6, CHANGE COMPUTER RECORD, que se muestra en la 

figura E7.11. Este es un programa interactivo en línea para cambiar la información de 
la computadora. Agregue los tres procesos siguientes. Cree entradas en el depósito 
para cada uno de los procesos, así como también el flujo de datos. Cuando esté com¬ 
pleto, ponga el zoom al 100 por ciento y arregle las flechas del flujo de datos que no 
estén rectas, y mueva las etiquetas de los flujos de datos para darle una apariencia más 
profesional. Imprima el diagrama a lo ancho de la página. 

a. El proceso 6.6, VALIDATE CHANGES. Este proceso edita cada campo de cam¬ 
bio para que sea válido. La entrada es KEYED CHANGES. Los campos de salida 
son CHANGE ERRORS (flujo de interfaz) y VALID CHANGES (para el proce¬ 
so 6.7). 

b. El proceso 6.7, CONFIRM CHANGES. Este proceso es una confirmación visual 
de los cambios. El operador tiene una oportunidad para rechazar los cambios o 
aceptarlos. La entrada es VALID CHANGES. Los campos de salida son REJEC- 
TED CHANGES (flujo de interfaz) y CONFIRMED CHANGES (para el proce¬ 
so 6.8). 
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Diagrama de flujo de datos, CHANGE COMPUTER RECORD. 


c. El proceso 6.8, REWRITE COMPUTER MASTER. Este proceso reescribe el regis¬ 
tro COMPUTER MASTER con los cambios en el registro. La entrada es CONFIR- 
MED CHANGES. El flujo de salida es el registro COMPUTER MASTER, para el 
almacén de datos COMPUTER MASTER. 

E-6. Amplíe el diagrama de flujo de datos para el proceso 4, DELETE COMPUTER. La ta¬ 
bla siguiente resume la entrada, el proceso y la salida. Describa cada proceso y flujo de 
datos en el depósito. Cuando esté completo, ponga el zoom al 100 por ciento, arregle 
las líneas del flujo de datos que no estén alineadas correctamente, mueva las etiquetas 
del flujo de datos para darles una apariencia más profesional e imprima el diagrama. 

Proceso: 4.1 KEY DELETE ID 

Descripción: La ID de computadora se teclea interactivamente 

Entrada: 1. DELETED COMPUTER ID 

Salida: 1. KEYED DELETE 

Proceso: 4.2 OBTAIN COMPUTER RECORD 
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Descripción: 


Se lee el COMPUTER MASTER para asegurarse de que 
existe 

Entrada: 

1. 

KEYED DELETE (interfaz) 


2. 

COMPUTER RECORD, del almacén de datos 
COMPUTER MASTER 

Salida: 

1. 

NOT FOUND ERROR (interfaz) 


2. 

VALID COMPUTER RECORD 

Proceso: 

4.3 

CONFIRM COMPUTER DELETION 

Descripción: 


La información de la computadora se despliega en la 
pantalla para que el operador la confirme o la rechace 

Entrada: 

1. 

VALID COMPUTER RECORD 

Salida: 

L 

REJECTED DELETION (interfaz} 


2. 

CONFIRMED DELETION 

Proceso: 

4.4 

DELETE COMPUTER RECORD 

Descripción: 


El registro de la computadora es lógicamente (no 
físicamente) eliminado del almacén de datos 
COMPUTER MASTER mediante la reescritura del 
registro con una I de inactivo en el campo Record Code 

Entrada: 

1. 

CONFIRMED DELETION 
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Salida: 2. DELETED COMPUTER, una flecha de doble punta 

para el almacén de datos COMPUTER MASTER 

-■•íif E-7. Ejecute la característica de análisis del diagrama de flujo de datos (seleccione Diagra¬ 
ma Analyze y Current Diagram). Imprima el informe para cada uno de los diagramas 
de flujo de datos descritos en los problemas anteriores. Examine los diagramas y ob¬ 
serve los problemas encontrados. 

a A f E-8. Ejecute el informe de revisión de sintaxis (seleccione Repository y Syntax Check) 
para producir el informe Syntax Check para los diagramas. Examine e interprete la in¬ 
formación proporcionada. 

i 4f> E-9. Elabore un informe Undescribed Repository Entities para los diagramas producidos 

en los problemas anteriores. Seleccione Repository y Reports y elija las opciones ilus¬ 
tradas en la figura E7.12. Imprima el informe y tome nota de las correcciones que se 
necesitan hacer para completar el diseño. 
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ANÁLISIS DE SISTEMAS 
MEDIANTE DICCIONARIOS 
DE DATOS 


OBJETIVOS DE APRENDIZAJE " . r'i “• 

Una vez que haya dominado el material de este capítulo, podrá: 

1. Entender el uso de diccionarios de datos para analizar sistemas orientados a datos. 

2. Crear registros en los diccionarios de datos para los procesos, almacenes, flujos, estructuras y 
; elementos de datos lógicos y físicos de los sistemas estudiados, con base en los DFDs. 

3. Entender el concepto de repositorio para la información de proyectos y el rol de las herramientas 
CASE en su creación. 

4. Reconocer las funciones de los diccionarios de datos en la actualización y mantenimiento de sistemas 

de información» ,¡. n •.L’fri- ■ 
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EL DICCIONARIO DE DATOS 


El diccionario de datos es una aplicación especializada de los tipos de diccionarios usados 
como referencia en la vida cotidiana. ÉEdicciónário de datos es una obra de consulta con in¬ 
formación ácércá dé los datos (és décir ,.metadatos), compilada por los analistas de sistemase 
para guiarse en el análisis y diseño. Como un documento, el diccionario de datos recopila y 
coordina términos de datos específicos, y.Confirma lo que cada término significa para las di¬ 
ferentes personas en la organización. Los diagramas de flujo de datos tratados en el capítulo 
7 son un excelente punto de partida para recopilar entradas para el diccionario dé datos. 

Una razón importante para mantener un diccionario de datos es guardar datos ordenados. 
Esto significa que los datos deben, ser consistentes. Si usted guarda datos acerca del sexo de un 
hombre como "M" en un registro, "Masculino" en un segundo registro y como el número " 1" en 
un tercer registro, los datos no son Consistentes. Un diccionario de datos ayudará en este aspecto. 

Los diccionarios de datos automatizados (parte de las herramientas CASE mencionadas: 
anteriormente) son valiosos por su capacidad de hacer referencias cruzadas de los éléfnenA 
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tos de datos y el lugar donde se utilizan, permitiendo por tanto realizar cambios a todos los 
programas que comparten un elemento común, si esto fuera necesario. Esta característica 
suplanta el hacer cambios al azar, y evita el tener que esperar hasta que un programa deje de 
funcionar porque un cambio no se ha implementado en todos los programas que comparten 
el elemento que se ha actualizado. Evidentemente, los diccionarios de datos automatizados 
se vuelven importantes para los sistemas grandes que producen miles de elementos de 
datos que requieren catalogación y referencias cruzadas. 


NECESIDAD DE ENTENDER EL DICCIONARIO DE DATOS 

Muchos sistemas de administración de base de datos están equipados con un diccionario 
de datos automatizado. Estos diccionarios pueden ser complejos o sencillos. Algunos dic¬ 
cionarios de datos computarizados catalogan automáticamente los elementos de datos 
cuando se hace la programación; otros simplemente proporcionan una plantilla para moti¬ 
var a la persona que llene el diccionario a que lo haga de una manera uniforme para cada 
entrada. 

A pesar de la existencia de los diccionarios de datos automatizados, entender qué datos 
conforman un diccionario de datos, las convenciones usadas en estos últimos y cómo se desa¬ 
rrolla un diccionario de datos, son problemas que el analista de sistemas debe tener siempre 
presentes durante el esfuerzo de sistemas. Entender el proceso de compilar un diccionario 
de datos puede ayudar al analista de sistemas a visualizar el sistema y su funcionamiento. Las 
próximas secciones permiten al analista de sistemas ver la lógica detrás de lo que existe tanto 
en los diccionarios automatizados como en los manuales. 

Además de proporcionar documentación y eliminar la redundancia, el diccionario de 
datos se podría usar para: 

1. Validar la integridad y exactitud del diagrama de flujo de datos. 

2. Proporcionar un punto de partida para desarrollar pantallas e informes. 

3. Determinar el contenido de los datos almacenados en archivos. 

4. Desarrollar la lógica para los procesos del diagrama de flujo de datos. 

E [ DEPÓSiTO DE DATOS 

Aunque el diccionario de datos contiene información de los datos y procedimientos, una 
colección más grande de información de proyectos se llama depósito. El concepto de 
depósito es uno de los muchos impactos de las herramientas CASE y podría contener lo 
siguiente: 

1. Información sobre los datos mantenidos por el sistema, incluyendo flujos de datos, 
almacenes de datos, estructuras de registros y elementos. 

2. Lógica de procedimientos. 

3. Diseño de pantallas e informes. 

4. Relaciones entre datos, por ejemplo cómo se vincula una estructura de datos con 
otra. 

5. Requerimientos del proyecto y productos del sistema final. 

6. Información sobre la administración del proyecto, tal como itinerarios de entrega, logros, 
problemas pendientes de solución y usuarios del proyecto. 

Como se muestra en la figura 8.1, el diccionario de datos se crea examinando y describien¬ 
do los contenidos de los flujos de datos, almacenes de datos y procesos. Cada almacén de 
datos y flujo de datos se debe definir y expandir para incluir los detalles de los elementos 
que contienen. La lógica de cada proceso se debe describir usando los datos que fluyen ha¬ 
cia el proceso o los que salen de él. Se deben detectar y resolver omisiones y otros errores de 
diseño. 

Se deben desarrollar las cuatro categorías del diccionario de datos —flujos de datos, 
estructuras de datos, elementos de datos y almacenes de datos— para fomentar el entendi¬ 
miento de los datos del sistema. En el capítulo 9 se presenta la lógica de procedimientos. 
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Diagrama de flujo de datos 


Diccionario de datos 




Para ilustrar cómo se crean las entradas del diccionario de datos, usamos un ejemplo pa¬ 
ra la División de Catálogos de World's Trend. Esta compañía vende ropa y otros artículos 
por correo utilizando un sistema de pedidos por teléfono libre de cargo (o enviando por fax 
el formulario de pedido] y a través de Internet mediante formularios Web personalizados. 
Independientemente de la forma en que se origine el pedido, los datos esenciales que cap¬ 
tura el sistema son los mismos para los tres métodos. 

El formulario de pedido de World's Trend que se muestra en la figura 8.2 da algunas 
pistas de lo que se debe introducir en un diccionario de datos. Primero es necesario captu¬ 
rar y almacenar el nombre, la dirección y el número telefónico de la persona que hace el 
pedido. A continuación se procede con los detalles del pedido: la descripción del artículo, 
el tamaño, el color, el precio, la cantidad, etc. También se debe determinar la forma de pago 
del cliente. Una vez terminada esta labor, los datos se podrían almacenar para un uso poste¬ 
rior. Este ejemplo se usa a través de todo el capítulo para ilustrar cada parte del diccionario 
de datos. 


Cómo se relacionan los 


diccionarios de datos con 
los diagramas de flujo de datos. 


DEFINICIÓN DE LOS FLUJOS DE DATOS 

Por lo general, los flujos de datos son los primeros elementos que se definen. Las entradas y 
salidas del sistema se determinan mediante las entrevistas y la observación de los usuarios, 
y el análisis de documentos y de otros sistemas existentes. La información capturada pa¬ 
ra cada flujo de datos se podría resumir usando un formulario que contenga la siguiente 
información: 

1. ID, un número de identificación opcional. A veces éste se codifica usando un esquema 
para identificar el sistema y la aplicación del sistema. 

2. Un solo nombre descriptivo para este flujo de datos. Este nombre es el texto que debe 
aparecer en el diagrama y se debe referenciar en todas las descripciones que usen el flujo 
de datos. 

3. Una descripción general del flujo de datos. 

4. La fuente dél flujo de datos. Esta podría ser una entidad externa, un proceso o un flujo 
de datos proveniente de un almacén de datos. 

5. El destino del flujo de datos (los mismos elementos que se describieron en la fuente). 

6. Algo que indique si el flujo de datos es un registro que está entrando o saliendo de un 
archivo o un registro que contiene un informe, formulario o pantalla. Si el flujo de datos 
contiene datos que se usan entre los procesos, se designa como interno. 

7. El nombre de la estructura de datos que describe los elementos encontrados en este flujo 
de datos. Para un flujo de datos simple, podrían ser uno o varios elementos. 
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8. El volumen por unidad de tiempo. Los datos podrían ser registros por día o cualquier 
otra unidad de tiempo. 

9. Un área para comentarios adicionales y anotaciones sobre el flujo de datos. 

Una vez más podemos usar nuestro ejemplo de la División de Catálogos de World’s Trend 
del capítulo 7 para ilustrar un formulario terminado. La figura 8.3 es un ejemplo de la des¬ 
cripción del flujo de datos que representa la pantalla usada para agregar un nuevo PEDIDO 
DEL CLIENTE y para actualizar los archivos del cliente y del artículo. Observe que la en¬ 
tidad externa CLIENTE es el origen y que el PROCESO 1 es el destino* proporcionando 
una referencia con el diagrama de flujo de datos. La marca en el cuadro "Pantalla" indica que 
el flujo representa una pantalla de entrada. Podría ser cualquier pantalla, como la de un 
mainframe, una interfaz gráfica de usuario (GUI) o una página Web. La descripción detalla¬ 
da del flujo de datos podría aparecer en este formulario, o se podría representar como una 
estructura de datos. 

Los flujos de datos para todas las entradas y salidas se deben describir primero, debido 
a que por lo general representan la interfaz humana, seguidos por los flujos de datos interme- 
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Un formularlo de pedido de la 
División de Catálogos de World’s 
Trend. 
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dios y los flujos de datos que entran y salen de los almacenes de datos. Los detalles de cada 
flujo de datos se describen usando elementos, llamados a veces campos, o una estructura de 
datos. 

Un flujo de datos simple se podría describir usando un solo elemento, tal como un nú¬ 
mero de cliente usado por un programa de consulta para encontrar el registro del cliente 
que coincida. En la figura 8.4 se muestra un ejemplo de un formulario electrónico. Para 
crear el formulario se usó Visible Analyst. 


DESCRIPCIÓN DE LAS ESTRUCTURAS DE DATOS 

Normalmente las estructuras de datos se describen usando una notación algebraica. Este 
método permite al analista producir una vista de los elementos que constituyen la estruc¬ 
tura de datos junto con información referente a dichos elementos. Por ejemplo, el analista 
indicará si hay muchos elementos iguales en la estructura de datos (un grupo de repetición), 
o si dos elementos podrían excluirse mutuamente. La notación algebraica usa los siguientes 
símbolos: 

1. Un signo de igual (=) significa "está compuesto de". 

2. Un signo de suma (+) significa "y". 

3. Las llaves {} indican elementos repetitivos, también llamados grupos de repetición o ta¬ 
blas. En el grupo podría haber un elemento de repetición o varios de ellos. El grupo de 
repetición podría tener condiciones, tal como un número fijo de repeticiones o límites 
superiores e inferiores para el número de repeticiones. 

4. Los corchetes [ ] representan una situación de uno u otro. Se podría representar un ele¬ 
mento u otro, pero no ambos. Los elementos listados entre los corchetes son mutuamente 
excluye ntes. 
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5. Los paréntesis () representan un elemento opcional. Los elementos opcionales se po¬ 
drían dejar en blanco en la entrada de las pantallas y podrían contener espacios o ceros 
para campos numéricos en las estructuras de archivos. 

La figura 8.5 es un ejemplo de la estructura de datos para agregar un pedido del cliente en la 
División de Catálogos de World's Trend. Cada pantalla de CLIENTE NUEVO se compone 
de las entradas que se encuentran a la derecha de los símbolos de igual. Algunas entradas son 
elementos, pero otras, como NOMBRE DEL CLIENTE, DIRECCIÓN y TELÉFONO, 
son grupos de elementos o registros estructurales. Por ejemplo, NOMBRE DEL CLIENTE 
está constituido por NOMBRE, INICIAL DEL SEGUNDO NOMBRE y APELLIDO. Ca¬ 
da registro estructural se debe definir aún más hasta que el grupo entero se divida en los 
elementos que lo componen. Observe que a la definición de la pantalla de PEDIDO DEL 
CLIENTE le siguen las definiciones para cada registro estructural. Incluso un campo tan 
simple como el NUMERO TELEFÓNICO se define como una estructura para que el códi¬ 
go de área se pueda procesar individualmente. 

A los registros estructurales y elementos que se usan en muchos sistemas diferentes se 
les da un nombre que no denota ningún sistema, tal como calle, ciudad y código postal, los 
cuales no reflejan el área funcional en la que se usan. Este método permite al analista defi¬ 
nir dichos registros una vez y usarlos en muchas aplicaciones diferentes. Por ejemplo, una 
ciudad podría ser la ciudad del cliente, ciudad del proveedor o ciudad del empleado. Ob¬ 
serve que el uso de paréntesis para indicar que (INICIAL DEL SEGUNDO NOMBRE), 
(DEPARTAMENTO) y (EXPANSIÓN DEL CÓDIGO POSTAL) es información opcional 
del PEDIDO (pero no más de uno). Para indicar la condición ÓR, se encierran las opcio¬ 
nes en corchetes y se separan con el símbolo ',. 
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ESTRUCTURAS DE DATOS LÓGICAS Y FÍSICAS 

Cuando las estructuras de datos se definen primero, sólo se incluyen los elementos de datos 
que el usuario vería, tal como un nombre, dirección y saldo a pagar. Esta fase es el diseño lógi¬ 
co, el cual muestra qué datos necesita el negocio para sus operaciones diarias. Con el diseño 
lógico como base, el analista diseña a continuación las estructuras de datos físicas, las cuales 
incluyen los elementos adicionales necesarios para implementar el sistema. Los siguientes son 
algunos ejemplos de elementos del diseño físico: 

1. Los campos clave se usan para localizar registros en una tabla de base de datos. Un 
ejemplo es el número de un artículo, el cual no se requiere para que un negocio funcio¬ 
ne pero es necesario para identificar y localizar los registros de la computadora. 




Elementos físicos agregados 
a la estructura de datos. 
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2. Los códigos para identificar el estado de los registros maestros, por ejemplo, para iden¬ 
tificar si un empleado está activo (actualmente empleado) o inactivo. Tales códigos se 
pueden mantener en archivos que generen información de impuestos. 

3. Los códigos de transacción se usan para identificar los tipos de registros cuando un 
archivo contiene diferentes tipos de registros. Un ejemplo es un archivo de crédito 
que contiene los registros para los artículos devueltos así como también los registros 
de pagos. 

4. Las entradas de grupos de repetición que llevan la cuenta de los elementos hay en el 
grupo. 

5. Los límites sobre el número de elementos aceptables en un grupo repetido. 

6. Una contraseña usada por un cliente que accede a un sitio Web seguro. 

La figura 8.6 es un ejemplo de la estructura de datos para un ESTADO DE FACTURA¬ 
CIÓN DEL CLIENTE, el cual muestra que la LÍNEA DEL PEDIDO es tanto un elemento 
de repetición como un registro estructural. Los límites de la LÍNEA DEL PEDIDO son de 
1 a 5, lo cual indica que el cliente podría pedir de uno a cinco artículos en esta pantalla. En 
pedidos subsecuentes podrían aparecer artículos adicionales. 

La notación del grupo de repetición podría tener varios formatos más. Si el grupo se re¬ 
pite un número fijo de veces, ese número se pone al lado de la llave de apertura, como en 
12 {Ventas mensuales}, donde siempre hay 12 meses al año. Si no se indica ningún número, 
el grupo se repite indefinidamente. Un ejemplo es un archivo que contiene un número in¬ 
definido de registros, tal como Archivo maestro de clientes = {Registros del cliente}. 

El número de entradas en los grupos de repetición también podría depender de una 
condición, tal como una entrada en el Registro maestro de clientes para cada artículo pedido. 
Esta condición se podría almacenar en el diccionario de datos como {Artículos comprados} 5, 
donde el 5 es el número de artículos. 


ELEMENTOS DE DATOS 

Cada elemento de datos se debe definir una vez en el diccionario de datos y también se po¬ 
dría introducir previamente en un formulario de descripción del elemento, como el que se 
ilustra en la figura 8.7. Las siguientes son las características que comúnmente se incluyen en 
el formulario de descripción del elemento: 

1. ID del elemento. Esta entrada opcional permite al analista construir entradas de diccio¬ 
nario de datos automatizadas. 

2. El nombre del elemento. El nombre debe ser descriptivo, único y basado en el propósi¬ 
to al cual está destinado el elemento en la mayoría de los programas o por el usuario 
principal del elemento. 
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descripción de un elemento 
de la División de Catálogos de 
World's Trend. 


3. Alias, los cuales son sinónimos u otros nombres para el elemento. Los alias son nombres 
usados por diferentes usuarios en diferentes sistemas. Por ejemplo, NUMERO DEL 
CLIENTE también se podría designar como NÚMERO DE CUENTA POR COBRAR 
o NUMERO DEL CONSUMIDOR. 

4. Una descripción breve del elemento. 

5. Si el elemento es base o derivado. Un elemento base es el que se teclea inicialmente en 
el sistema, tal como un nombre del cliente, dirección o ciudad. Los elementos base se 
deben almacenar en archivos. Los elementos derivados son creados por procesos como 
resultado de un cálculo. 

6. La longitud de un elemento. Algunos elementos tienen longitudes estándar. Por ejem¬ 
plo, en Estados Unidos la longitud para las abreviaturas de nombre de estado, los códi¬ 
gos postales y números telefónicos son estándar. Las longitudes podrían variar para 
otros elementos, y el analista y la comunidad de usuarios deben decidir en conjunto la 
longitud final con base en las siguientes consideraciones: 

a. Las longitudes de las cantidades numéricas se deben determinar calculando el nú¬ 
mero mayor que probablemente contendrán y después dejar un espacio razonable 
para la expansión. Las longitudes designadas para los totales deben ser lo bastante 
grandes para dar acomodo a la suma de los números que acumulen. 
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b. A los campos de nombre y dirección se les podría asignar longitudes con base en la 
tabla siguiente. Por ejemplo, un campo para el apellido de 11 caracteres dará aco¬ 
modo a 98 por ciento de los apellidos en Estados Unidos. 

c. Para otros campos, con frecuencia es útil examinar o muestrear los datos históricos 
encontrados en la organización para determinar el tamaño adecuado del campo. 


Campo 

Longitud 

Porcentaje de datos 
que se acomodarán (E. U.) 

Apellido 

11 

98 

Nombre 

18 

95 

Nombre de la compañía 

20 

95 

Calle 

18 

90 

Ciudad 

17 

99 

Si el elemento es demasiado 

pequeño, se 

truncarán los datos que se necesiten introdu- 


cir. El analista debe decidir cómo afectará esta situación a las salidas del sistema. Por 
ejemplo, si se trunca el apellido de algún cliente, por lo regular el correo aún se entre¬ 
garía; sin embargo, si se trunca la dirección de correo electrónico, se devolverá como no 
encontrada. 

7. El tipo de datos: numérico, fecha, alfabético o carácter que a veces se llama datos alfanu- 
méricos o de texto. En la figura 8.8 se muestran algunos de estos formatos. Los campos 
de carácter podrían contener una mezcla de letras, números y caracteres especiales. Si el 
elemento es una fecha, se debe determinar su formato —por ejemplo, MMDDAAAA—. 
Si el elemento es numérico, se debe determinar su tipo de almacenamiento. Hay tres 
formatos estándar para los mainframes; el decimal dividido en zonas, el decimal empa¬ 
quetado y el binario. El formato decimal dividido en zonas se usa para imprimir y des¬ 
plegar datos. El formato decimal empaquetado normalmente se usa para ahorrar espacio 
en los diseños de archivo y para elementos que requieren que en ellos se realice un nivel 
alto de aritmética. El formato binario es conveniente para los mismos propósitos que 
el formato decimal empaquetado pero su uso es menos común. 

Los formatos de las computadoras personales, tales como moneda, numérico o 
científico, dependen de cómo se utilizarán los datos. Los formatos numéricos se definen 
aún más como entero, entero largo, precisión sencilla, precisión doble, etc. Hay muchos 
otros tipos de formatos que se utilizan en los sistemas de PC. Unicode es un sistema de 


Algunos ejemplos de formatos de 
datos usados en sistemas de PC. 


Tipo de datos 

Bit . , : ., . 

Char, varchar, text 
Datetime, smalldatetime 
Decimal, numeric 

Float, real 

Int, smallint, tinyint 

Currency, rnoney, srnallrnoney ; : * 

Binary, varbinary, image 

Cursor, tirnestamp, uniqueidentifier'*/ 

Autonumber 


Significado 

Unvalprdel oO, un Valor de fajso/verdadero : 

Cualquier carácter alfanumérico 

Datos alfanurnéricbs,diversos formatos A 

Datos numéricos que son precisos para el último dígito signi¬ 
ficativo; pueden contener una parte entera y una decimal 

: Valores-de puntoflota;nte:que contienen un valor 
decimal aproximado - • 

Sólo datos enteros (dígitos enteros) 

Números moríetarips:preéjsospara cuatro lugares decimales 

Cadenas binarias (sonido, imágenes, video) 

Un valor ¡qué s emoreesü'Vaeíj una tese-de datos A 

Un número que siempre incrementa una unidad cuando 
se agrega un registro a una tabla de base de datos 
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Códigos de carácter de formato. 


codificación estandarizado para definir símbolos gráficos, tal como caracteres chinos o 
japoneses. Unicode se describe con mayor detalle en un capítulo posterior. 

8. Los formatos de entrada y salida se deben incluir, usando símbolos de codificación espe¬ 
ciales para indicar cómo se deben presentar los datos. En la figura 8.9 se ilustran dichos 
símbolos y su uso. Cada símbolo representa un carácter o dígito. Si el mismo carácter se 
repite varias veces, el carácter seguido por un número entre paréntesis que indica cuán¬ 
tas veces se repite el carácter, se sustituye con el grupo. Por ejemplo, XXXXXXXX se 
representaría como X(8). 

9. Los criterios de validación para asegurar que el sistema capture los datos correctos. Los 
elementos pueden ser discretos, lo cual significa que tienen ciertos valores fijos, o conti¬ 
nuos, con un rango parejo de valores. Los siguientes son criterios comunes de edición: 

a. Un rango de valores es conveniente para elementos que contienen datos continuos. 
Por ejemplo, en Estados Unidos el promedio de puntos de un estudiante podría ser 
de 0.00 a 4.00. Si hay un solo límite superior o inferior para los datos, se usa un lí¬ 
mite en lugar de un rango. 

b. Si los datos son discretos, lo apropiado es una lista de valores. Ejemplos son los có¬ 
digos que representan los colores de artículos para la venta por catálogo de World's 
Trend. 

c. Una tabla de códigos es conveniente si la lista de valores es extensa [por ejemplo, 
las abreviaturas de los nombres de los estados, los códigos telefónicos del país o los 
códigos telefónicos de área de Estados Unidos). 

d. Con frecuencia se incluye un dígito de verificación para las claves o los elementos 
de índice. 

10. Cualquier valor predeterminado que pudiera tener el elemento. El valor predeterminado 
se despliega en las pantallas de entrada y se usa para reducir la cantidad de datos que tu¬ 
viera que teclear el operador. Por lo regular, varios campos de cada sistema tienen valores 
predeterminados. Cuando use listas GUI o listas desplegables, el valor predeterminado 
es el que se encuentra seleccionado y resaltado. Al usar botones de opción, la opción pa¬ 
ra el valor predeterminado aparece seleccionada y al usar casillas de verificación, el valor 
predeterminado (ya sea "sf o "no"] determina si la casilla de verificación tendrá o no una 
marca de verificación inicial. 

11. Un área adicional para observaciones o comentarios. Aquí se podría indicar el formato 
de la fecha, si se requiere alguna validación especial, el método de dígito de verificación 
usado (lo cual se explica en el capítulo 15), etcétera. 

En la figura 8.10 se ilustra un ejemplo de un formulario de descripción de un elemento de 
datos de Visible Analyst. Como se muestra en el formulario, el NUMERO DEL CLIENTE se 
podría llamar NÚMERO DEL CONSUMIDOR en otra parte del sistema (quizás el código 
viejo escrito con este alias necesite ser actualizado). El formulario también es útil porque a 
través de él podemos saber que el elemento es una variable numérica con una longitud de 
seis caracteres. Esta variable puede ser tan grande como 999999 pero no menor que cero. 

Otro tipo de elemento de datos es un elemento alfabético. En la División de Catálogos 
de World's Trend se usan los códigos para describir colores: por ejemplo, AZ para el azul, BL 
para el blanco y VE para el verde. Cuando se implementa este elemento, los usuarios nece¬ 
sitarán una tabla para buscar el significado de estos códigos. (La codificación se analiza con 
más detalle en el capítulo 15.) 
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Pantallas de Visible Analyst que 
muestran la descripción de un 
elemento. Se requieren dos 
páginas para definir un elemento. 
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ALMACENES BE DATOS 


Todos los elementos base se deben almacenar en el sistema. También los elementos deri¬ 
vados se podrían almacenar en el sistema, tal como, para un empleado, el sueldo bruto 
acumulado a la fecha. Los almacenes de datos se crean para cada entidad de datos diferen¬ 
te que se almacenará. Es decir, cuando los elementos base de un flujo de datos se agrupan 
para formar un registro estructural, se crea un almacén de datos para cada registro estruc¬ 
tural único. 

Debido a que un flujo de datos dado podría mostrar sólo una parte de los datos colec¬ 
tivos que un registro estructural contiene, usted tendría que examinar muchas estructuras 
de flujo de datos diferentes para llegar a una descripción completa de un almacén de datos. 

La figura 8.11 es un formulario típico usado para describir un almacén de datos. La in¬ 
formación incluida en el formulario es la siguiente: 

1. El ID del almacén de datos. El ID es con frecuencia una entrada obligatoria para evitar 
que el analista almacene información redundante. Un ejemplo sería DI para el archivo 
MAESTRO DE CLIENTES. 

2. El nombre del almacén de datos, el cual es descriptivo y único. 

3. Un alias para el archivo, tal como MAESTRO DE CONSUMIDORES para el archivo 
MAESTRO DE CLIENTES. 


—— 

' i,ss 




Ejemplo de un.formulario de 
un a macen de datos para la.. 
División de Catálogos de World's 
Trend. 


n -'fe i/¡ ao ^st/cas del aim3cé 

■üsüss^Z, ffero : w 


T3 Secoenc;,, n 

u Directo 

Tamaño del bloque -_ 4 Ido 
Promedio; _ 42,0 00 


* tla>os ^^ 1 _ 

Estructura de ^ 

Clave principal —sagfes¿í sidjafe 

Ctates secundad ~ ‘ 

zzzn 

■—-- 

- la feffl ia 


_________ - 


musxsrn as. 

.■ ,;i, .■ 




ANALISIS DE SBTEMAS MEDIANTE DICCDNARIOS DE DATOS 


IlttlIBIW » 







4. Una breve descripción del almacén de datos. 

5. El tipo de archivo, manual o computarizado. 

6. Si el archivo es computarizado, el formato de archivo designa si se trata de un archivo 
de base de tipo tabla o si tiene el formato de un archivo plano tradicional. (Los forma¬ 
tos de archivo se detallan en el capítulo 13.] 

7. El número máximo y promedio de registros en el archivo así como también el crecimien¬ 
to anual. Esta información permite al analista predecir el espacio en disco que requerirá 
la aplicación y es necesaria para planear la adquisición del hardware. 

8. El nombre del conjunto de datos especifica el nombre del archivo, si se conoce. Este 
elemento se podría dejar en blanco en las primeras etapas del diseño. En la figura 8.12 
se muestra un formulario electrónico producido mediante Visible Analyst. Este ejemplo 
muestra que el archivo MAESTRO DE CLIENTES se almacena en una computadora 
como base de datos con un número máximo de 45,000 registros. (En el capítulo 13 se 
explican los registros y las claves usadas para ordenar la base de datos.) 

9. La estructura de datos debe usar un nombre que se encuentre en el diccionario de datos, 
y proporcionar un vínculo a los elementos de este almacén de datos. Como alternati¬ 
va, los elementos de datos se podrían describir en el formulario de descripción del 
almacén de datos o en la pantalla de la herramienta CASE para el almacén de datos. Las 
claves primaria y secundaria deben ser elementos (o una combinación de elementos) de 
la estructura de datos. En el ejemplo, el NÚMERO DEL CLIENTE es la clave principal 
y debe ser única. El NOMBRE DEL CLIENTE, CÓDIGO POSTAL y CANTIDAD 
COMPRADA A LA FECHA son las claves secundarias usadas para controlar la secuencia 
de registros en los informes y para localizar directamente los registros. (En el capítulo 
13 se describen las claves.) Los comentarios se usan para información que no se ajusta 
a ninguna de las categorías anteriores. Podrían incluir información referente a tiem¬ 
pos para realizar copias de seguridad o actualizaciones, aspectos de seguridad u otras 
consideraciones. 
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CREACIÓN DEL DICCIONARIO DE DATOS 


Las entradas del diccionario de datos se podrían crear después de completar el diagrama 
de flujo de datos, o se podrían construir conforme se desarrolle el diagrama de flujo de da¬ 
tos. El uso de notación algebraica y registros estructurales permite al analista desarrollar el 
diccionario de datos y los diagramas de flujo de datos mediante un enfoque jerárquico de 
arriba hacia abajo. Por ejemplo, el analista podría crear un flujo de datos de un Diagrama 
0 después de las primeras entrevistas y, al mismo tiempo, hacer las entradas preliminares 
del diccionario de datos. Típicamente, estas entradas consisten en los nombres de los flu¬ 
jos de datos encontrados en el diagrama de flujo de datos y sus estructuras de datos co¬ 
rrespondientes. 

Después de realizar varias entrevistas adicionales para descubrir los detalles del sistema, el 
analista extenderá el diagrama de flujo de datos y creará los diagramas hijos. Posteriormente se 
modifica el diccionario de datos para incluir los nuevos registros estructurales y elementos 
recabados en las entrevistas, observación y análisis de documentos posteriores. 

Cada nivel de un diagrama de flujo de datos debe usar datos adecuados para el nivel. El 
Diagrama 0 debe incluir únicamente formularios, pantallas, informes y registros. Conforme 
se creen los diagramas hijos, el flujo de datos que entre y salga de los procesos será cada vez 
más detallado, incluyendo los registros estructurales y los elementos. 

La figura 8.13 ilustra una parte de dos niveles del diagrama de flujo de datos y las entra¬ 
das correspondientes del diccionario de datos para producir el recibo de nómina de un em¬ 
pleado. El proceso 5, del Diagrama 0, es un ejemplo general de la producción de un RECIBO 
DE NÓMINA DEL EMPLEADO. La entrada correspondiente del diccionario de datos para 
el REGISTRO DEL EMPLEADO muestra el NUMERO DEL EMPLEADO y cuatro regis¬ 
tros estructurales, la vista de los datos obtenidos anteriormente en el análisis. Del mismo 
modo, también se definen como una serie de estructuras el REGISTRO DEL ARCHIVO DE 
TIEMPO y el RECIBO DE NÓMINA DEL EMPLEADO. 

Es importante que los nombres de los flujos de datos en el diagrama de flujo de datos 
hijo estén contenidos como elementos o registros estructurales en el flujo de datos del pro- 




Estructura de datos 
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ceso padre. Regresando al ejemplo, INFORMACIÓN DEL SUELDO [entrada del proceso 
5.3, CALCULAR MONTO DEL SUELDO ACTUAL) es un registro estructural contenido 
en el REGISTRO DEL EMPLEADO [entrada del proceso 5], Del mismo modo, el SUEL¬ 
DO BRUTO [salida del proceso 5.3.4, un proceso de nivel inferior que no se muestra en la 
figura] está contenido en el registro estructural MONTO DEL SUELDO ACTUAL [salida 
del proceso padre 5.3, CALCULAR MONTO DEL SUELDO ACTUAL). 

ANÁLISIS DE LAS ENTRADAS Y SALIDAS 

Un paso importante en la creación del diccionario de datos es identificar y categorizar el flu¬ 
jo de datos de entrada y salida del sistema. Los formularios de análisis de entrada y salida, co¬ 
mo el ejemplo que se muestra en la figura 8.14, se podrían usar para organizar la información 
obtenida de las entrevistas y análisis de documentos. Observe que este formulario contiene 
los siguientes campos comúnmente incluidos: 

1. Un nombre descriptivo para la entrada o salida. Si el flujo de datos está en un diagra¬ 
ma lógico, el nombre debe identificar el propósito de los datos [por ejemplo, INFOR- 
MACIÓN DEL CLIENTE). Sin embargo, si el analista está trabajando en el diseño 
físico o si el usuario ha declarado explícitamente la naturaleza de la entrada o salida, el 
nombre debe incluir esa información con respecto al formato. Ejemplos son ESTADO 
DE LACTURACIÓN DEL CLIENTE y AVERIGUACIÓN DE DETALLES DEL 
CLIENTE. 



Ejemplo de un formulario de 
análisis de entrada y salida 
para la División de Catálogos 
de World's Trend. 
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m ¿QUIERE HACERLA EN GRANDE EN EL TEATRO? 

Ü-J ¡MEJORE SU DICCIÓN(ARIO)! 

) ' ' .. 


Cuando usted cruza la puerta de Merman's, Annie Oaklea lo saluda 
calurosamente: "Estoy encantada con el trabajo que hiciste con los dia¬ 
gramas de flujo de datos. Me gustaría que siguieras desempeñando el 
rol de analista de sistemas de Merman's y ver si con el tiempo puedes te¬ 
jer un.nuevo sistema de información para nuestro inventario de disfraces. 
Desgraciadamente, algunos de los términos que utilizas no concuerdan 
muy bien con el lenguaje de Shakespeare. Supongo que es cuestión de 
resolver ese pequeño problema de traducción". 

Aprovechando los elogios iniciales de Annie, usted no se desanima 
por las últimas palabras de ella. Usted considera que un diccionario de 
datos basado en los diagramas de flujo de datos del proceso de renta y 
devolución, podrían resultar un "éxito de taquilla". 


Empiece por redactar entradas para un sistema manual con tanto 
detalle como sea posible. Prepare dos entradas de proceso de datos, dos 
entradas de flujo de datos, dos entradas de almacén de datos, una en¬ 
trada de estructura de datos y cuatro entradas de elementos de datos 
usando los formatos de este capítulo. La descripción precisa de los ele¬ 
mentos de datos interrelacionados dará como resultado "buenos comen¬ 
tarios de los críticos de obras teatrales". (Refiérase a la Oportunidad de 
consultoría 7.1.) 


2. El contacto del usuario responsable para la clarificación de detalles adicionales, retro- 
alimentación del diseño y aprobación final. 

3. Si los datos son de entrada o salida. 

4. El formato del flujo de datos. En la fase del diseño lógico, el formato podría ser inde¬ 
terminado. 

5. Elementos que indican la secuencia de los datos en un informe o pantalla (quizás en 
columnas]. 

6. Una lista de elementos, incluyendo sus nombres, longitudes y si son base o derivados y 
sus criterios de edición. 

Una vez que se haya completado el formulario, cada elemento se debe analizar para determi¬ 
nar si se repite, si es opcional o si se excluye mutuamente con otro elemento. Los elementos 
que hay en un grupo o que regularmente se combinan con algunos otros elementos en mu¬ 
chas estructuras se deben agrupar en un registro estructural. 

Estas consideraciones se pueden ver en el formulario de análisis de entrada y salida ter¬ 
minado para la División de Catálogos de World's Trend (véase la figura 8.14}. En este ejemplo 
de ESTADO DE FACTURACIÓN DEL CLIENTE, el NOMBRE DEL CLIENTE, APE¬ 
LLIDO DEL CLIENTE e INICIAL DEL SEGUNDO NOMBRE DEL CLIENTE se deben 
agrupar en un registro estructural. 


DESARROLLO DE ALMACENES DE DATOS 


Otra actividad relativa a la creación del diccionario de datos es el desarrollo de los almacenes 
de datos. Hasta ahora, hemos determinado qué datos necesitan fluir de un proceso a otro. Es¬ 
ta información se describe en estructuras de datos. Sin embargo, la información podría estar 
almacenada en diversos lugares, y el almacén de datos podría ser diferente en cada lugar. 
Mientras que los flujos de datos representan datos en movimiento, los almacenes de datos re¬ 
presentan datos en reposo. 

Por ejemplo, cuando un pedido llega a World's Trend (véase la figura 8.15), contiene en 
su mayor parte información temporal, es decir, la información necesaria para surtir ese pedido 
particular, pero parte de la información podría estar almacenada permanentemente. Ejem¬ 
plos de esta última incluyen información de los clientes (para poder enviarles catálogos] e 
información de los artículos (debido a que dichos artículos aparecerán en muchos otros 
pedidos de clientes]. 

Los almacenes de datos contienen información de una naturaleza permanente o semi- 
permanente (temporal). NÚMERO DEL ARTÍCULO, DESCRIPCIÓN y COSTO DEL 
ARTÍCULO son ejemplos de información relativamente permanente. Al igual que la TASA 
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Almacenes de datos derivados 
de un pedido pendiente de la 
División de Catálogos de World's 
Trend. 


Maes'™ de clientes = 


prometiente 

Nómbrentela t 


Dirección + 

Teléfono+ 

CSÍ^*"** 

"■«n» (te artícu/os- nr 


'<"’**<> del 


Cantidad d/spon/b/e 

Wúmer 0 def efiente + 

SS 2 S 2 **' 




S 5 r" p '®«* 


Gastos de en vfo < 


íESa»* 


Forma de i 


A o de tarjeta h 0 
crédito = De 


mmZt¡Z,lT ait0U 

Número del artfe..,„ 
ca n M ad pedida + 

- Ca "“.dad enviada + 

Pre «o actual 


fWorJd's Trend 1 . 

^ .^ ***** : Masíe ^nt: wsa/ 




DE IMPUESTO. Sin embargo, cuando el COSTO DEL ARTÍCULO se multiplica por la 
TASA DE IMPUESTO, el IMPUESTO COBRADO se calcula (o deriva}. Los valores deri¬ 
vados no se tienen que almacenar en un almacén de datos. 

Cuando los almacenes de datos se crean para un solo informe o pantalla, nos referimos 
a ellos como "vistas del usuario", porque representan la manera en que el usuario quiere ver 
la información. 


USO DEL DICCIONARIO DE DATOS 


El diccionario de datos ideal es automatizado, interactivo, en línea y evolutivo. Conforme el 
analista de sistemas descubre cosas nuevas de los sistemas de la organización, se agregan ele¬ 
mentos de datos al diccionario de datos. Por otro lado, el diccionario de datos no es un fin en 
sí mismo y nunca debe serlo. Para evitar desviarse del propósito principal con la construc¬ 
ción de un diccionario de datos completo, el analista de sistemas debe verlo como una 
actividad paralela al análisis y diseño de sistemas. 

Para maximizar su potencial, el diccionario de datos se debe vincular a varios progra¬ 
mas de sistemas para que cuando un elemento se actualice o elimine del diccionario de datos, 
ocurra lo mismo en la base de datos. El diccionario de datos se vuelve simplemente una 
curiosidad histórica si no se mantiene actualizado. 

El diccionario de datos se podría usar para crear pantallas, informes y formularios. Por 
ejemplo, examine la estructura de datos para el LISTADO DE SELECCIÓN DE PEDIDOS 


262 


FSjrtíítlf 


EL PROCESO DE ANALISIS 






de World's Trend en la figura 8.16. Debido a que se han definido los elementos necesarios y 
sus longitudes, el proceso de crear documentos físicos consiste en organizar los elementos 
de una forma agradable y funcional siguiendo lincamientos de diseño y el sentido común. 
Los grupos de repetición se convierten en columnas y los registros estructurales se agrupan 
en la pantalla, informe o formulario. En la figura 8.17 se muestra el diseño del informe para 
el LISTADO DE SELECCIÓN DE PEDIDOS de World’s Trend. Observe que NOMBRE y 
APELLIDO se agrupan en NOMBRE y que CANTIDAD [SELECCIONADA y PEDIDA], 
SECCIÓN, NÚMERO DE ESTANTE, NÚMERO DEL ARTÍCULO, DESCRIPCIÓN 
DEL ARTÍCULO, TAMAÑO y COLOR forman una serie de columnas, debido a que son 
los elementos de repetición. 

La estructura de datos y los elementos de un almacén de datos se usan normalmente 
para generar el código fuente correspondiente en lenguaje de computadora que posterior¬ 
mente se integra en los programas de cómputo. El diccionario de datos se podría usar en 
conjunto con un diagrama de flujo de datos para analizar el diseño del sistema, detectar fa¬ 
llas y áreas que se necesitan aclarar. Algunas consideraciones son: 

1. Todos los elementos base en un flujo de datos de salida deben estar presentes en un flujo 
de datos de entrada en el proceso que produce la salida. Los elementos base se teclean 
y nunca deben ser creados por un proceso. 
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Número del pedido: 9 
Numero del oliente: 

Nombre: 

Cálle: 

Departamento: 

Ciudad, estado,-cód. postal: 

País: 

Teléfono: 

— Cantidad — 
Seleccionada Pedida 


mJAíorld's Trend 

Formulario de selección de pedidos 


Fecha del pedido Z9/99/99 g9 


xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 

xxxxxxxxxxxxxxxxxxxxxxxxxxxx 

xxxxxxxx 

xxxxxxxxxxxxxxxxxxxxxxxxxxxx, XX 

XXXXXXXXXXXXXXXXXXXXXXXXXXXX 99099-ZZZZ 
(999)999-9999 


Sección . 

Número 

Número . 

de:estante. 

'' del artículo 

XXXXX 

99999j 

-999999 " 

xxxxx’ 

99999 

999999 

XXXXX' 

99999 . 

999999 

XXXXX - 

99999;. 

999999 v 

xxxxx- ■■ 

99999 

999.999 

xxxxx 

99999 

¡999999 = ' - 


Descripción del artículo 

' xxxxxxxxxxxxxxxxxxxxxxxxxxxx- 

XXXXXXXXXXXXXXXXXXXXXXXXXXXX , 
XXXXXXXXXXXXXXXXXXXXXXXXXXXX", 

xxxxxxxxxxxxxxxxxxxxxxxxxxxx.. 
xxxxxxxxxx.xxxxxxxxxxxXxxxxxx : - 
’ xxxxxxxxxxxxxxxxxxxxxXxxxxxX'. 

XXXXXXXXXXXXXXXXXXXXXXXXXXXX ■" ■ 
XXXXXXXXXXXXXXXXXXXXXXXXXXXX 


Número de artículos: Z9 


.XXXXXXXXXXXX^ 

■.■xxxxxxxxxxxx'' 
xxxxxxxxxxxx- 

■■XXXXXXXXXXXX 
XXXXXXXXXXXX¡' 
;. XXXXXXXXXXXX -. 

■ xxxxxxxxxxxx.';' 
xxxxxxxxxxxx 


xxxxxxxx 
xxxxxxxx 
: xxxxxxxx . 
xxxxxxxx 
xxxxxxxx 
xxxxxxxx 
xxxxxxxx 
xxxxxxxx 


Listado de selección de pedidos 
creado a partir del diccionario 
de datos. L-/ ;, !: 


2. Un elemento derivado debe ser creado por un proceso y debe ser la salida de por lo me¬ 
nos un proceso en el cual no es entrada. 

3. Los elementos que están presentes en un flujo de datos que entran o salen de un almacén 
de datos se deben contener en el almacén de datos. 

Si se empieza temprano, un diccionario de datos puede ahorrar bastante tiempo en las fases 
de análisis y diseño. El diccionario de datos es la fuente común en la organización para con¬ 
testar preguntas y arreglar controversias acerca de cualquier aspecto de la definición de los 
datos. Un diccionario de datos actualizado puede servir como una referencia excelente pa¬ 
ra los esfuerzos de mantenimiento en los sistemas desconocidos. Los diccionarios de datos 
automatizados pueden servir de referencia para las personas y los programas. 


USO DE LOS DICCIONARIOS DE DATOS PARA CREAR XML 


El Lenguaje de Marcación Extensible (XML] es un lenguaje que se puede usar para inter¬ 
cambiar datos entre los negocios. Es similar a HTML, el lenguaje de marcación usado para 
crear páginas Web, pero es más poderoso. HTML se ocupa principalmente de dar formato 
a un documento; XML aborda el problema de compartir datos cuando los usuarios tienen 
diferentes sistemas de cómputo y software. Si todos usáramos el mismo software, XML no 
seria tan necesario. 

Una vez que se ha creado un documento de XML, los datos se podrían transformar en 
varios formatos de salida diferentes y desplegarse en muchas formas distintas, incluyendo 
impresiones, páginas Web, salida para un dispositivo portátil y archivos de formato de docu¬ 
mento portable (PDF). Por tanto, los datos, que son el contenido del documento, están 
separados del formato de salida. El contenido de XML se define una vez como datos y 
después se transforma cuantas veces sea necesario. 
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La ventaja de usar un documento de XML es que el analista podría seleccionar sólo los 
datos que un departamento interno o un socio externo necesitan para funcionar. Esto garanti¬ 
za la confidencialidad de los datos. Por ejemplo, una compañía transportadora podría recibir 
sólo el nombre del cliente, su dirección, el número del artículo y la cantidad por enviar, pero 
no información de la tarjeta de crédito u otros datos financieros. Este enfoque eficaz también 
reduce la sobrecarga de información. 

Por lo tanto, XML es una forma de definir, ordenar, filtrar y traducir datos en un lenguaje 
universal de datos que cualquiera puede usar. XML se podría crear desde bases de datos, un 
formulario, programas de software o tal vez teclearse directamente en un documento, editor 
de texto o en un programa de captura de XML. 

El diccionario de datos es un punto de partida ideal para desarrollar contenido de 
XML. La clave para usar XML es crear una definición estándar de los datos. Esto se lo¬ 
gra utilizando un conjunto de etiquetas, o nombres de datos, que se incluyen antes y des¬ 
pués de cada elemento de datos o estructura. Las etiquetas son los metadatos, o datos so¬ 
bre los datos. Los datos se podrían subdividir en elementos más pequeños y estructuras 
hasta que todos los elementos se hayan definido. La figura 8.18 ilustra un diccionario de 
datos que contiene información del cliente, del pedido y del pago. Cada cliente podría 
hacer muchos pedidos. La estructura se define en las dos columnas izquierdas y el código 
de XML aparece en la columna derecha. Como puede ver, CLIENTE está conformado 
por NÚMERO, NOMBRE, DIRECCIÓN, SALDO ACTUAL, varias entradas de INFOR¬ 
MACIÓN DE PEDIDO y un PAGO. Algunas de éstas son estructuras que se subdividen 
aún más. 

El documento de XML tiende a reflejar la estructura del diccionario de datos. La pri¬ 
mera entrada (aparte de la línea de XML que identifica el documento) es <cliente>, la cual 
define toda la colección de información del cliente. Los símbolos de menor que (<) y mayor 
que (>) se usan para identificar los nombres de la etiqueta (similar a HTML). La última lí¬ 
nea del documento de XML es una etiqueta de cierre, </cliente>, que significa el final de la 
información del cliente. 

La etiqueta de número, <numero>, se define a continuación porque es la primera en¬ 
trada en el diccionario de datos, seguida por el número real y la etiqueta de cierre, </numero>. 
NOMBRE es una estructura que consiste en APELLIDO, NOMBRE y una INICIAL DEL 
SEGUNDO NOMBRE opcional. En el documento de XML, esta estructura empieza con 
<nombre> seguida por <apellido>, <nombre_pila> e <inicial_segundo_nombre>. Debido a 
que no se permiten espacios en los nombres de etiquetas de XML, por lo regular se usa un 
guión bajo para separar las palabras. La etiqueta de cierre </nombre> significa el final 
del grupo de elementos. 

La sangría se usa para mostrar qué estructuras contienen elementos. Observe que 
<direccion> es similar a <cliente>, pero cuando llegamos a <informacion_pedido> hay 
una gran diferencia. 

Hay múltiples entradas para <informacion_pedido>, cada una contiene <numero_pe- 
dido>, <fecha_pedido>, <fecha_envio> y <total>. Debido a que el pago se hace ya sea 
mediante cheque o tarjeta de crédito, sólo uno de éstos podría estar presentar. En nuestro 
ejemplo, el pago se realiza con cheque. 

Con frecuencia la estructura de elementos del contenido de XML se establece median¬ 
te una definición del tipo de documento (DTD). Una DTD se usa para determinar si el 
contenido del documento de XML es válido; es decir, si se apega al orden y tipo de datos 
que se deben presentar en el documento. La DTD es fácil de crear y bien apoyada por el 
software estándar. Una vez que se haya completado la DTD, se podría usar para validar 
el documento de XML usando herramientas estándar de XML. 

La ventaja de usar XML para definir datos es que, en el formato de XML, los datos se 
almacenan en un formato de texto puro y no dependen de ningún software patentado. 

Los grupos u organizaciones de diferentes industrias se podrían involucrar en la de¬ 
finición de una estructura de XML específica de su gremio de modo que todas las partes 
involucradas entiendan el significado de los datos. Esto es muy importante cuando el 
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Diccionario de datos 


Nombre = 


Dirección = 


Información del 
pedido = 


Tarjeta de crédito ^ 


Número + 

Nombre + 

Dirección + 

Saldo actual + 
^Información del pedldol - 


Apellido + 

Nombre + 

(Inicial del segundo nombre) 


Calle + 

(Departamento) ■ 
Ciudad + 

Estado + 

Código postal + 
País 


<?xml vers¡on="1.0"?> 

<cliente> 

<numero>15008</numero> 

<nombre> 

<apellido>Núñez</apellido> 

<nombre>Sandra</nombre> 

«¡n'gnig^segundO-nombresU/imc'al-SegundO-nombreí 

<dlrecclon> (|p 

<calle>Octavio Sentíes l4</calle> 

<apartamento>lnterior 16< apartamento |g¡ 

<ciudad>Distrito Federak/ciudad> 

<os:aoc>DF< estaco 

<zip>09060</zip> jpj 

<pais>México</pais> M 

</direccion> 

<saldo_actual>123.45</saldo_actual> M 

<informacion_pedido> fcy 



<numero_pedldo>00123</numero_pedldo> 

ggíi 


<fecha_pedldo>2004-08-05</fecha_pedldo> 


Número del pedido + 

<fecha_envlo>2004-08-09</fecha_envio> 


Fecha del pedido + 

<total>1345.89</total> 


Fecha de envío + 

</¡nformaclon_pedldo> 

Sf 

Total 

<¡nformaclon_pedldo> 

gj 


<numero_pedldo>00127</numero_pedldo> 



<fecha_pedldo>2004-08-08</fecha_pedldo> 



<fecha_envio>2004-08-12</fecha_envlo> 



[Cheque, 1 Tarjeta de crédito] - 
Fecha de pago + 


Fecha de pago h 
M onto del pago 


Número de cheque 


Número de tarjeta de crédito h 
F echa de expiración 


<total>240.00</total> 

</¡nformaclon_pedldo> 

<pago> 

<cheque> 

<numero cheque>7234</numero cheque> 
</cheque> 

<fecha_pago>2004-09-04</fecha_pago> 

<monto_pago>1585.89</monto_pago> 

</pago> 

</cllente> 
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Diccionario de datos y un 
ejemplo del documento 
correspondiente de XML con 
datos de muestra. 


nombre de un elemento puede tener varios significados. Un ejemplo es "estado", el cual 
podría significar una abreviación del estado de residencia o el estado de un pedido o una 
cuenta. 
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RESUMEN 

Mediante un enfoque jerárquico de arriba hacia abajo, el analista de sistemas usa los diagramas 
de flujo de datos para empezar a compilar un diccionario de datos, el cual es un trabajo de re¬ 
ferencia que contiene datos acerca de datos, o metadatos, de todos los procesos de datos, alma¬ 
cenes, flujos, estructuras y elementos lógicos y físicos del sistema bajo estudio. Una forma de 
empezar es incluir todos los elementos de datos que contengan los diagramas de flujo de datos. 
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EXPERIENCIA CON HYPERCASE® 


"Usted está haciendo las cosas bastante bien. Snowden dice que usted le ha dado toda clase 
de nuevas ideas para dirigir el nuevo departamento. Eso tiene mucho mérito, sobre todo si 
se considera que él tiene sus propias ideas. Por ahora espero que usted haya tenido la opor¬ 
tunidad de hablar con todas las personas que haya necesitado: definitivamente el propio 
Snowden, Tom Ketcham, Daniel Hill y el señor Hyatt." 

"¿El señor Hyatt es un poco evasivo, no es así? Creo que lo conocí ya bien entrado en 
mi tercer año. Espero que usted pueda averiguar algo de él en mucho menos tiempo. Ah, 
pero, cuando consigue verlo, es una persona muy especial, ¿no es así? Y esos locos aviones. 
Uno de ellos casi me golpea en la cabeza en el estacionamiento. ¿Pero cómo se puede uno 
enojar, si quien los vuela es El Jefe? También tiene su jardín oriental secreto —o más bien 
debo decir privado— en su oficina. No, usted nunca verá ese jardín en los planos. Usted tie¬ 
ne que llegar a conocerlo muy bien para que él se lo enseñe, pero apuesto a que es el único 
que hay así en Tennessee y tal vez en todo el país. El se enamoró de los maravillosos jardi¬ 
nes que vio en el sudeste de Asia cuando era joven. Sin embargo, él va más allá todavía. El 
señor Hyatt está consciente del valor de la contemplación y la meditación. Si él expresa una 
opinión, puede usted estar seguro que la ha pensado muy bien." 
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PREGUNTAS DE HYPERCASE 

1. Mencione brevemente los elementos de datos que haya encontrado en tres informes 
diferentes de MRE. 

2. Con base en sus entrevistas con Snowden Evans y otros, mencione los elementos de datos 
que considera que debe agregar al sistema de informes de proyectos de la Unidad de 
Capacitación para recopilar mejor los datos importantes del estado del proyecto, fechas 
límite del proyecto y estimaciones del presupuesto. 

3. Cree una entrada en el diccionario de datos para un nuevo almacén de datos, un nuevo 
flujo de datos y un nuevo proceso de datos que usted esté sugiriendo con base en sures- 
puesta a la pregunta 2. 

4. Sugiera una lista de nuevos elementos de datos que podrían ser útiles para Jimmie 
Hyatt pero con los cuales evidentemente él no cuenta ahora. 


DATA FDOW DESCRIPTION 


Ñame: Assignment Record 

Description: Contains a record comingfioni or goingto the Assignment M áster 
Source: Múltiple |[Destination: Múltiple 

Type of data ñow. File ijVolume/Time: Varíes 

Data Structure Traveling With The Flow: 

Re s ourc e Numb er H - 
TaskNumber + 

A s signment Duration + 


tlilliliiililil 

En HyperCase, usted puede 
consultar el diccionario de datos 


Aesignment Scheduled Mart Date 
A s signment P ere ent Complete d 


jCíomments: A general dataflow containing a record to orfromüie AssignmentMaster 


Refererice; : Back • Print- 
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Una colección más grande de información del proyecto se llama depósito. Las herramien¬ 
tas CASE permiten al analista crear un depósito que podría incluir información acerca de los 
flujos de datos, almacenes, estructuras de registro y elementos; de las pantallas de lógica 
de procedimientos y diseño de informes; de las relaciones de datos; de los requerimientos del 
proyecto y de las liberaciones del sistema final, y acerca de la información de administración 
del proyecto. 

Cada entrada en el diccionario de datos contiene el nombre del elemento, una descrip¬ 
ción en español, alias, elementos de datos relacionados, el rango, la longitud, codificación y la 
información de edición necesaria. El diccionario de datos es útil en todas las fases del análi¬ 
sis, diseño y por último de la documentación, debido a que es la fuente autorizada de cómo 
se usan y definen los elementos de datos en el sistema. Muchos sistemas grandes tienen dic¬ 
cionarios de datos computarizados que incluyen referencias cruzadas de todos los programas 
contenidos en la base de datos que usan un elemento de datos en particular. 


PALABRAS Y FRASES CLAVE 

decimal dividido en zonas 

decimal empaquetado 

definición del tipo de documento (DTD) 

depósito 

diccionario de datos 
elemento base 
elemento de datos 
elemento de repetición 


elemento derivado 
entregables del sistema 
estructura de datos 
estructura de datos física 
formato binario 
grupo de repetición 

Lenguaje de Marcación Extensible (XML) 
registro estructural 


PALABRAS DE REPASO 

1. Defina el término diccionario de datos. Defina qué son los metadatos. 

2. ¿Cuáles son las cuatro razones para compilar un diccionario de datos completo? 

3. ¿Qué información contiene un depósito de datos? 

4. ¿Qué es un registro estructural? 

5. Mencione las ocho categorías específicas que cada entrada debe contener en un diccio¬ 
nario de datos. Proporcione una definición breve de cada categoría. 

6. ¿Cuáles son las diferencias básicas entre las entradas del diccionario de datos preparadas 
para los almacenes de datos, estructuras de datos y elementos de datos? 

7. ¿Por qué se usan los'registros estructurales? 

8. ¿Cuál es la diferencia entre las estructuras de datos lógica y física? 

9. Describa la diferencia entre los elementos base y los derivados. 

10. ¿Cómo se relacionan las entradas de un diccionario de datos con los niveles de un grupo 
de diagramas de flujo de datos? 

11. Mencione los cuatro pasos que se siguen en la compilación de un diccionario de datos. 

12. ¿Por qué la compilación de un diccionario de datos no se debe visualizar como un fin 

en si misma. 7 

13. ¿Cuáles son los beneficios principales de usar un diccionario de datos? 

14. ¿Qué describe el Lenguaje de Marcación Extensible (XML]? 

15. ¿Qué es una definición del tipo de documento? 

16. ¿Cómo garantiza una definición del tipo de documento que un documento de XML 
contiene todos los elementos necesarios? 


PROBLEMAS 

1. Joe, uno de los miembros de su equipo de análisis de sistemas, basado en la figura 
7.EX1 del capítulo 7, hizo la entrada siguiente para el diccionario de datos usado por 
Marilyn's Tours: 

ELEMENTO DE DATOS = EL TURISTA * * * * PAGO 
ALIAS = PAGO DEL TURISTA 


EL PROCESO DE ANÁLISIS 







CARACTERES = 12-24 
RANGO = $5.00-$l,000 

VARIABLES = $5.00, $10.00, $15.00 hasta $1,000, y cualquier cantidad intermedia 
en dólares y centavos 

PARA CALCULAR = COSTO TOTAL DE TODOS LOS PASEOS, CUALQUIER 
IMPUESTO APLICABLE EN EL ESTADO DE NUEVA YORK, menos cualquier 
DEPÓSITO DE LA RESERVACIÓN realizado. 


a. ¿Esto es realmente un elemento de datos? ¿Por qué sí o por qué no? 

b. Vuelva a escribir la entrada del diccionario de datos para el PAGO DEL TURISTA, 
clasificándolo nuevamente si es necesario. Use el formulario adecuado para la cla¬ 
sificación que elija. 

2. Pamela, la analista de sistemas, ha tenido un avance importante en el entendimiento del 
movimiento de los datos en el almacén de ropa de Bonton. Pamela está creando un 
diccionario de datos para compartir lo que ha hecho con otros miembros de su equipo 
y con el jefe de la franquicia de Nueva York. 

a. Escriba una entrada en el diccionario de datos de Pamela para uno de los flujos 
de datos que usted describió en su diagrama de flujo de datos en el problema 1 del 
capítulo 7. Procure que sea lo más completo posible. 

b. Escriba una entrada en el diccionario de datos de Pamela para uno de los almace¬ 
nes de datos que usted describió en su diagrama de flujo de datos en el problema 1 
del capítulo 7. Procure que sea lo más completo posible. 

3. Cecile, la gerente de la librería con la que su equipo de análisis de sistemas ha estado tra¬ 
bajando para construir un sistema de inventario computarizado, piensa que uno de los 
miembros de su equipo se está volviendo una molestia pues le hace preguntas sumamen¬ 
te detalladas acerca de los elementos de datos que se usan en el sistema. Por ejemplo, él pre¬ 
gunta, "¿Cecile, cuánto espacio, en caracteres, ocupa la inscripción de un número de ISBN?" 

a. ¿Qué problemas se crean al hacerle directamente al gerente preguntas relacionadas 
con las entradas del diccionario de datos? En un párrafo mencione los problemas que 
puede ver en el enfoque del miembro de su equipo. 

b. En un párrafo, explique al miembro de su equipo cómo puede recopilar mejor la 
información para el diccionario de datos. 
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4. La Motion Manufacturing Company ensambla bicicletas, triciclos, monopatines, patine¬ 
tas y otro equipo de deportes al aire libre. Cada uno de estos productos se construye 
usando muchas partes que varían de producto a producto. Las entrevistas con el encarga¬ 
do del departamento de las partes han producido una lista de elementos para la LISTA 
DE PARTES DEL PRODUCTO, la cual muestra qué partes se usan en la fabricación de 
cada producto. En la figura 8.EX1 se ilustra un prototipo de la LISTA DE PARTES DEL 
PRODUCTO. Cree una entrada de diccionario de datos para la LISTA DE PARTES 
DEL PRODUCTO. El encargado del departamento le informa que nunca hay más de 50 
partes diferentes para cada producto. 

5. Analice los elementos de la LISTA DE PARTES DEL PRODUCTO y cree la estructura 
de datos para los almacenes de datos del archivo MAESTRO DE PRODUCTOS y del 
archivo MAESTRO DE PARTES. 

6. ¿Cuáles elementos de la LISTA DE PARTES DEL PRODUCTO son derivados? 

7. La Caribbean Cruise Company organiza vacaciones en un crucero de diferente du¬ 
ración en varias partes. Cuando los clientes llaman para verificar la disponibilidad de 
un crucero, se usa una INVESTIGACIÓN DE DISPONIBILIDAD DE CRUCERO, 
ilustrada en la figura 8.EX2, para proporcionarles la información. Cree la estructura 
del diccionario de datos para la INVESTIGACIÓN DE DISPONIBILIDAD DE 
CRUCERO. 

8. Mencione los archivos maestros que se podrían necesitar para implementar la INVES¬ 
TIGACIÓN DE DISPONIBILIDAD DE CRUCERO. 

9. Los siguientes puertos de escala están disponibles para la Caribbean Cruise Company: 



J= A LL A l'. 3< TJ* , L'y, A 
muestra la disponibilidad de un 
crucero. 


Kingston 

Bahía de Montego 
Santo Domingo 
San Juan 


Puerto Príncipe Nassau 

St. Thomas Freeport 

Hamilton Point-á-Pitre 

Puerto España Santa Lucía 


Cree el elemento PUERTO DE ESCALA. Examine los datos para determinar el tamaño 
y formato del elemento. 

10. El gerente de comercio electrónico de la Moonlight Mugs, una compañía que vende jarros 
para café personalizados, desea enviar información a otra compañía que mantiene el al¬ 
macén y proporciona servicios de envío. La información del pedido se obtiene de un 
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sitio Web seguro, incluyendo el número del cliente, nombre y dirección, número telefóni¬ 
co, dirección de correo electrónico, número del producto y cantidad, así como también 
información de la tarjeta de crédito. La compañía de envío también maneja artículos 
para otros negocios pequeños. Defina un documento de XML que incluya sólo la infor¬ 
mación que necesita la compañía de envío para embarcar artículos al cliente. 

11. Una vez que se ha enviado el pedido del problema 10, la compañía de envío devuelve 
información a Moonlight Mugs, incluyendo el nombre del cliente y dirección, número 
de seguimiento del transportista, datos enviados, cantidad pedida, cantidad enviada y 
cantidad devuelta. Defina un documento de XML que incluirá la información enviada 
a Moonlight Mugs. 


PROYECTOS DE GRUPO 

1. Reúnase con su grupo y use una herramienta CASE o un manual de procedimiento 
para desarrollar las entradas de diccionario de datos para un proceso, flujo de datos, al¬ 
macén de datos y estructura de datos basadas en los diagramas de flujo de datos que 
usted completó para Maverick Transport en los ejercicios de grupo del capítulo 7. Co¬ 
mo grupo, póngase de acuerdo en algunas suposiciones necesarias para hacer entradas 
completas de cada elemento de datos. 

2. Su grupo debe desarrollar una lista de métodos para ayudarle a hacer las entradas de 
diccionario de datos completas para este ejercicio, así como también para futuros pro¬ 
yectos. Por ejemplo, estudiar informes existentes, basarlos en los diagramas de flujo de 
datos nuevos o existentes, etcétera. 
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"Podemos usar los diagramas de flujo de datos que elaboramos al crear las entradas de 
diccionario de datos para todos los flujos de datos y los almacenes de datos". Chip le dice a 
Anna en su siguiente reunión. Cada uno de estos componentes tiene una entrada de 
composición en el depósito. Por lo tanto, los registros creados por el sistema de cómputo 
están vinculados directamente a los componentes del diagrama de flujo de datos que 
describen datos. 

Anna y Chip se reúnen para dividirse el trabajo de crear registros y elementos. "Desa¬ 
rrollaré el diccionario de datos para la parte de software del sistema", dice Anna. 

"[Qué bueno, porque a mí me encanta el hardware!", responde Chip de buena gana. 
Primero se crean los registros o estructuras de datos. Éstos podrían contener elementos, 
la parte fundamental de la estructura de datos, y también podrían contener otros registros 
llamados registros estructurales. Visible Analyst también mantiene relaciones entre los com¬ 
ponentes gráficos, registros y elementos que se podrían usar para análisis y elaboración de 
informes. 

Anna empieza a crear los registros del software mediante la información de las entre¬ 
vistas y las pantallas prototipo. Debido a que la salida de un sistema determinará qué datos 
es necesario almacenar y obtener a través de las pantallas de entrada de datos, el punto de 
partida es el flujo de datos de salida SOFTWARE INSTALLATION LIST. Este prototipo 
identifica algunos de los elementos que se deben almacenar en el archivo SOFTWARE 
MASTER: 

SOFTWARE INVENTORY NUMBER 
VERSIÓN NUMBER 
NUMBER OF DISKETTES 
CAMPUS LOCATION 
TITLE 

DISKETTE SIZE 
HARDWARE INVENTORY 
NUMBER 

ROOM LOCATION 

También se examinan otros informes y pantallas prototipo de salida. Los elementos adicio¬ 
nales se obtienen de la pantalla prototipo ADD SOFTWARE. Estos elementos se organizan 
en una secuencia lógica para el archivo SOFTWARE MASTER. Se usan las siguientes reglas 
para organizar elementos en un registro: 

1. El elemento clave principal que identifica de manera única al registro. Un ejemplo 
es el SOFTWARE INVENTORY NUMBER. 

2. Información descriptiva, como TITLE, VERSIÓN NUMBER y PUBLISHER. 

3. Información que se actualiza periódicamente, como NUMBER OF COPIES. 

4. Los elementos que se repiten, como HARDWARE INVENTORY NUMBER, el 
cual indica en qué computadoras se ha instalado el software. 

A continuación, se crea el registro SOFTWARE MASTER mediante el depósito de Visi¬ 
ble Analyst. En la figura E8.1 se muestra la pantalla de descripción para crear un registro. 
[Nota: Esta pantalla podría diferir de la que usted tenga en su copia de Visible Analyst. Para 
ver la pantalla con el mismo formato, haga clic en el menú Options y después marque la casi¬ 
lla de verificación Classical User Interface.) Observe el área de entrada para un alias, o un 















P?.rualla de descripción de ütinegístro, SOFT”<VRC-. ‘HMÍTlüf:. 


nombre diferente para el registro, utilizada por un grupo de usuarios diferente. Debido a que 
cada usuario podría referirse al mismo registro con un nombre diferente, todos los nombres 
se deben documentar, con lo cual se consigue una mejor comunicación entre los usuarios. 

Cada elemento o registro estructural necesita definirse como parte del registro entero, 
y se introduce en el área Composition. Si el elemento o registro estructural es un grupo que 
se repite, el nombre se encierra entre llaves ({]) y el número de veces que se repite se pone 
antes del nombre. Si los datos son claves, se pone un código entre corchetes [[ ]) antes del 
nombre. El símbolo [pk] representa una clave primaria. El símbolo [akn] representa una 
clave alterna, donde n puede ser 1, 2, 3, etc., y denota cada clave diferente o grupo de cam¬ 
pos que, cuando se combinan, conforman una clave secundaria. Cuando un grupo de campos 
constituye una clave secundaria, ésta se llama clave concatenada. 

Examine el SOFTWARE MASTER. Contiene una clave primaria del SOFTWARE 
INVENTORY NUMBER y una clave secundaria concatenada conformada por TITLE, 
OPERATING SYSTEM y VERSIÓN NUMBER. 

Visible Analyst le permite describir fácilmente cada registro estructural o elemento que 
compone el registro principal. Anna pone el cursor en cada nombre del área Composition y 
hace clic en el botón Jump. Se despliegan pantallas adicionales del registro y el elemento y se 
introduce información detallada. 
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"[Es grandioso!", piensa Anna. "Es tan fácil introducir los detalles, y con este método no 
olvidaré accidentalmente describir un elemento". 

Chip también se impresiona con la sencillez para crear el diccionario de datos. Siguiendo 
un proceso similar al de Anna, crea una descripción de registro para el archivo COMPUTER 
MASTER, el cual contiene una tabla de cinco tarjetas internas y dos registros estructurales, 
PERIPHERAL EQUIPMENT y MAINTENANCE INFORMATION. El área Composition 
para introducir los nombres de elemento o registro es una región que se puede desplazar, lo 
cual significa que se podrían teclear más líneas de las que se ven en el área de despliegue. Con¬ 
forme se agregan entradas en la parte inferior de esta región, las entradas de la parte superior 
se desplazan fuera del área. 

Chip decide describir detalladamente cada elemento conforme se agregan al registro. 
En la figura E8.2 se muestra la pantalla de descripción de elemento para el HARDWARE 
INVENTORY NUMBER. Observe las áreas para introducir los atributos del elemento. Se 
podrían incluir diversos alias junto con una definición. El área Notes contiene información 
útil sobre el elemento. Chip y Anna usan esta área para introducir criterios de edición adi¬ 
cionales y otros comentarios útiles. La descripción para el HARDWARE INVENTORY 
NUMBER detalla cómo se usa este número para dar un seguimiento físico a las máquinas. 




Pantalla de descripción de un elemento, HARDWARE INVENTORY NUMBER. 
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HARDWARE INVEN! O'RY NUMBFR, con é] desp egue de las características de. elemente. 


Al hacer clic en la etiqueta Physical Characteristics se despliega una segunda pantalla 
para el HARDWARE INVENTORY NUMBER, que se ilustra en la figura E8.3. Contiene 
un área que muestra en cuáles estructuras se encuentra el elemento, así como también un 
área para el tipo de dato, la longitud y el cuadro que se usó para describir el formato de los 
datos. Cada uno de estos cuadros es una entrada codificada, similar a los usados en los len¬ 
guajes de programación. A continuación se muestran algunos ejemplos de los códigos: 

9 Representa datos numéricos: Sólo se podrían introducir números al elaborar 
prototipos. 

A Alfabético: Sólo se podrían introducir caracteres alfabéticos. 

X Alfanumérico: Se podría introducir cualquier tipo de caracteres. 

Z Supresión de ceros: Reemplaza los ceros con espacios. 

$ Signo de moneda: Reemplaza los ceros principales con un signo de dólar. 

Chip tiene cuidado de incluir las entradas completas para estas áreas, incluyendo cual¬ 
quier valor predeterminado y si la entrada podría ser nula o no. 

Anna y Chip repiten este proceso para todos los elementos de cada registro. Este esfuer¬ 
zo toma tiempo pero vale la pena. Después de que se crean los primeros registros, es más 
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fácil crear las estructuras de los registros restantes. Visible Analyst tiene una característica 
de búsqueda que proporciona listas de los elementos contenidos en el diseño. 

"Creo que hemos diseñado un grupo completo de elementos", menciona Chip en una 
reunión de revisión. 

"Sí", contesta Anna. "Hay informes que nos mostrarán los detalles de las estructuras 
de datos y nos ayudarán a descubrir duplicaciones y omisiones. Pongamos a trabajar a Visible 
Analyst para que produzca diseños de registros en lugar de nosotros." 

La característica Reporte se usó para imprimir diseños de registros para todos los archivos 
maestros. 

ANÁLISIS DE REGISTROS Y ELEMENTOS 

"Usemos ahora realmente el poder de Visible Analyst", dice Anna. "Veamos qué tan bien 
hemos diseñado nuestros datos." # 

"¿Qué quieres decir?", pregunta Chip. 

"He estado estudiando las características de análisis de Visible Analyst, y hay muchas 
opciones para revisar la consistencia y exactitud de nuestro diseño", contesta Anna. "El 
primer paso es usar la característica Reporte para producir un informe de resumen de los 
elementos que hemos agregado. Después podemos examinar la lista en busca de duplica¬ 
ciones y redundancia." 

La figura E8.4 es un ejemplo de una parte del informe de resumen de elementos des¬ 
plegado usando Microsoft Internet Explorer. Los analistas examinarían cuidadosamente el 
contenido y buscarían redundancia o elementos definidos más de una vez. Con frecuencia 
estas redundancias son fáciles de localizar porque la lista se ordena por el nombre del ele¬ 
mento. Al parecer, los elementos HARDWARE INVENTORY NUMBER y HARDWARE 
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Aciive Software Code Data Eiement 

Description: 

Code to determine if software is currentíy in use. 

Board Code Data Eiement 

Description: 

Code used to indícate the type ofinteraal Computer board. 

Board Ñame Data Eiement 

Description; 

The ñame of an interaal Computer board, Used as a match for the 

board code. 

Brand Ñame Data Eiement 

Description: 

The ñame ofthe omputer brand. 

Brand Subtotal Data Eiement 

Description: 

The total for one brand of Computer. 

Campus Code Data Eiement 

Description: 

A code used to store a campus budding. 

Campus Description Data Eiement 

Description: 

The description of a Central Pacific University campus building. This field 

matches the Campus Code. 

Campus Location Data Eiement 

, Description: 

Campus where the Computer is located. 
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NUMBER y los elementos SOFTWARE INVENTORY NUMBER y SOFTWARE NUM 
son elementos duplicados. Otros duplicados, como ROOM LOCATION y LOCATION, son 
más difíciles de localizar. 

"Posteriormente debemos usar la opción No Location References, la cual muestra todos 
los elementos que no se incluyen en ningún registro", dice Aúna. 

"[Esto es fantástico!", exclama Chip. "Esta opción muestra el trabajo de diseño que 
necesita realizarse. Deberíamos producir este informe para todos los componentes del 
diseño." 

Los elementos se agregaron a otras estructuras o se eliminaron como duplicados. Al 
producir el informe No Location References por segunda ocasión no se reveló ningún 
elemento aislado. 

"Bueno, supongo que se ha terminado la parte de datos del diseño del sistema", dice 
Chip. 

"Supones mal", contesta Anna. "Apenas empezamos el análisis. La característica Report 
Query nos proporcionará mucha información del diseño, tanto para el análisis como para la 
documentación." 

Los analistas seleccionan como su primera opción un informe llamado Def Entities 
without Compositíon. El informe muestra entradas que son un almacén de datos o estructura 
de datos y tienen una entrada de composición. La salida muestra que no hay ningún registro 
erróneo. La siguiente consulta del informe es Elements without Pictures, y muestra todos 
los elementos que no tienen definido algún cuadro. En la figura E8.5 se ilustra una parte de 
esta vista preliminar del informe. El último informe que Chip y Anna crean se llama Undefi- 
ned Elements, el cual indica todos los elementos que no se han definido; es decir, su nombre 
se encuentra en el depósito, pero no tienen características físicas. 
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Department Ñame 

Data Element 




! Description: 





i University department ñame 





Hardware Subtotal 

Data Element 




Description: 





■ Tota ! for alí hardware in a selected A "oup. 





Monitor Ñame 

Data Element 




Dascription: 





The ñame of the monitor contained within hardware records. 





Neict Preveníive Maintenance Date 

Data Element 




i Description: 





£ This is the calculated date that the neKt preventive maintenance should be 



?: 

performed on a given Computer. 





Phone Number 

Data Eíement 




Description: 





Any phone number. 




11 

Problem Description 

Data Element 




Descripüon: 





Describes a Computer problem that has been reported. 





3 Purchase Order Number 

Data ElemenE 




Descripüon: 





P Untversíty Purchase Order Number - Unique for each order placed. 




Quantiry Ordered 

Data Element 




j B.epair Status 

Data Element 




■ Dsscriptiofi: 





The status of a repair. 
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Elementos sin una vista preliminar de cuadro 
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"Realmente estoy impresionado con este análisis", afirma Chip. "Desde que hemos co¬ 
rregido los errores en nuestro diseño, he comprendido qué tan fácil es sentirse seguro de 
que el diseño se ha completado cuando hay diferencias y omisiones que aún necesitan nues¬ 
tra atención." 

"Aún no hemos terminado. Hay algunas matrices útiles que proporcionarán documen¬ 
tación para cualquier cambio que necesitáramos hacer en el futuro. Produzcamos la matriz 
Data Elements versus Data Structures, la cual muestra registros y sus elementos", sugiere 
Anna. 

La característica Report tiene la capacidad de producir informes así como también ma¬ 
trices en forma de cuadrícula. Muestra todos los elementos y las estructuras de datos en que 
se encuentran. Esta matriz se usa para ver el efecto de cambiar un elemento, ya que muestra 
las estructuras de datos correspondientes que se deben cambiar. 
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Informe Cómposition Matrix. 
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La siguiente matriz creada es Diagram Location Matrix, la cual muestra todos los alma¬ 
cenes de datos y los diagramas donde se localizan. Esta información es útil si es necesario 
hacerle un cambio al almacén de datos, porque indicará dónde se necesitan cambiar los pro¬ 
gramas y la documentación. 

Una última matriz es Composition Matrix, la cual muestra todos los elementos de datos 
y los almacenes de datos en donde se encuentran. En la figura E8.6 se ilustra una parte de 
esta matriz. Esta matriz proporciona una descripción a Chip y a Anna de los elementos que 
se podrían almacenar de manera redundante, es decir, en varios almacenes de datos en lugar 
de tan sólo en uno. 

"Hay muchos otros informes y matrices que nos serían útiles", dice Anna. "Algunos de 
éstos se deben usar después para la documentación y el seguimiento de cualquier cambio 
que se proponga. Realmente estoy muy satisfecha de lo que hemos logrado." 



EJERCICIOS 



E-l. 




E-2. 

E-3. 


Use Visible Analyst para ver el archivo COMPUTER MASTER. Pase a la estructura 
de datos y examine los elementos y los registros estructurales. 

Imprima el registro SOFTWARE MASTER mediante la característica Report. 

Use el botón Jump para llegar a Software Record Structure. Elimine los elementos 
siguientes: 


ACTIVE SOFTWARE CODE 
INSTALLATION COMPUTER 
SOFTWARE EXPERT 



E-4. 



E-5. 



Modifique el registro SOFTWARE CHANGES, y haga los cambios correspondientes 
en el registro SOFTWARE MASTER. Las modificaciones son las siguientes: 

a. Agregue un [pk], para la clave primaria, delante de SOFTWARE INVENTORY 
NUMBER. 

b. Agregue los elementos siguientes: COMPUTER BRAND, COMPUTER MODEL, 
MEMORY REQUIRED, MONITOR REQUIRED, PRINTER REQUIRED, SITE 
LICENSE y NUMBER OF COPIES. 

Modifique el registro COMPUTER ADD TRANSACTION, el cual contiene los nue¬ 
vos registros de computadoras que se colocarán en el almacén de datos COMPUTER 
MASTER. 

a. Inserte BRAND ÑAME y MODEL arriba de SERIAL NUMBER. 

b. Ponga CAMPUS LOCATION y ROOM LOCATION después de SERIAL 
NUMBER. 

c. Agregue los elementos siguientes en la parte inferior de la lista: HARD DRFVE 1, 
HARD DRIVE 2 y FLOPPY DRIVE. 

d. Elimine el elemento INTERNAL BOARDS, el cual se determinará después de la 
instalación de la computadora. 

Modifique INSTALLED SOFTWARE TRANSACTION, el cual se usa para actualizar 
el registro SOFTWARE MASTER y producir la lista SOFTWARE INSTALLATION 
LISTING. Elimine TITLE y VERSIÓN NUMBER, debido a que se podrían obtener 
del SOFTWARE MASTER y son redundantes. Agregue el HARDWARE INVEN¬ 
TORY NUMBER, especificando la computadora de instalación. Elimine CAMPUS 


<0 Los ejercicios precedidos por un icono Web indican material de valor agregado disponible en el sitio Web de 
este libro. Los estudiantes pueden descargar una muestra de una base de datos de Microsoft Access que 
pueden utilizar para completar los ejercicios. 
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LOCATION y ROOM LOCATION, debido a que son elementos de la computadora 
de instalación. 

0 E-7. Vea la entrada de alias para SOFTWARE MASTER TABLE. 

E-8. Modifique el almacén de datos INSTALLED SOFTWARE. Agregue el registro de 
composición INSTALLED SOFTWARE TRANSACTION. Los elementos del ín¬ 
dice son SOFTWARE INVENTORY NUMBER y HARDWARE INVENTORY 
NUMBER. 

E-9. Defina el almacén de datos SOFTWARE LOG FILE. Este archivo se usa para almace¬ 
nar la información sobre los nuevos registros de software, más la fecha, tiempo e ID 
de usuario de la persona que introduce el registro. Los elementos del índice son 
SOFTWARE INVENTORY NUMBER, TITLE, VERSIÓN (una clave concatenada) 
y SOFTWARE CATEGORY. 

E-10. Defina el almacén de datos PENDING COMPUTER ORDERS. Este archivo se 
crea cuando se hace una orden de compra de computadoras nuevas, y lo actualiza 
el sistema de cómputo. Introduzca un comentario en el área Notes para indicar 
que el número promedio de registros es 100. Los elementos del índice son PUR- 
CHASE ORDER NUMBER y una clave concatenada que consiste en BRAND 
ÑAME y MODEL. 

E-l 1. Vea la entrada para el flujo de datos SOFTWARE RECORD. Haga clic en el botón 
Jump en el área Composition y examine el registro SOFTWARE MASTER. Haga 
clic en Back para regresar a la pantalla de descripción del flujo de datos. 

¡¡¡^ E-l2. Modifique el flujo de datos SOFTWARE UPGRADE INFORMATION. El registro 
de composición es SOFTWARE UPGRADE INFORMATION. 

E-13. Modifique el flujo de datos SOFTWARE CROSS-REFERENCE REPORT. El registro 
de composición es SOFTWARE CROSS-REFERENCE REPORT. 

E-14. Modifique la entidad de flujo de datos para INSTALL UPDATE. Este flujo actualiza 
el registro COMPUTER MASTER con la información de instalación. Su estructura 
de datos es INSTALL UPDATE RECORD. Incluya un comentario para indicar que 
procesa aproximadamente 50 registros por mes para actualizar el COMPUTER 
MASTER. 

E-l 5. Use el flujo de datos INSTA LE UPDATE para pasar al (y crear el) INSTALL UPDATE 
RECORD. Dé una definición basada en la información proporcionada en el problema 
anterior. Introduzca los elementos siguientes: 

HARDWARE INVENTORY NUMBER (clave primaria) 

CAMPUS LOCATION 
ROOM 

INTERNAL BOARDS (aparece cinco veces) 

HARD DRIVE 2 
PRINTER 

MAINTENANCE INTERVAL 
DATEINSTALLED 

. E-16. Cree la descripción del flujo de datos para SOFTWARE INSTALLATION LIST. Este 
flujo contiene información sobre paquetes de software específicos y de las máquinas 
donde se debe instalar el software. La composición debe incluir el SOFTWARE INS- 
TALLATION LISTING, una estructura de datos. 

í¡j$f E-l 7. Use la SOFTWARE INSTALL LIST para pasar a (y por consiguiente crear) el SOFT¬ 
WARE INSTALLATION LISTING. Los elementos en el listado son los siguientes: 

SOFTWARE INVENTORY NUMBER 
TITLE 

VERSIÓN NUMBER 
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HARDWARE INVENTORY NUMBER 
CAMPUS LOCATION 
ROOM LOCATION 


# E-18. 
E-19. 

E-20. 



E-21. 


Modifique e imprima el elemento HARDWARE SUBTOTAL. Cambie el tipo a 
Numeric, la longitud a 6,2 y el cuadro a Z, ZZZ, ZZ9.99. 

Modifique e imprima el elemento MONITOR ÑAME, el resultado de una búsqueda 
en la tabla utilizando un código de monitor. El tipo debe ser Character, la longitud 
30yelcuadroX(30). 

Modifique e imprima el elemento DEPARTMENT ÑAME. Cree un alias STAFF 
DEPARTMENT ÑAME. En el área Notes, teclee el comentario siguiente: Table of 
codes: Department Table. El tipo debe ser Character, la longitud 25 y el cuadro 
X(25). 

Cree las siguientes descripciones del elemento. Use los valores proporcionados en la 
tabla. Cree los nombres alternativos y definiciones que sean necesarios con base en 
lo que conozca del elemento. 



Ñame 

PURCHASE ORDER NUMBER 

PROBLEM DESCRIPTION 

Type 

Character 

Character 

Length 

7 

70 

Picture 

9999999 

X(70) 

Ñame 

TOTAL 

NEXT PREVENTIVE 


COMPUTER 

MAINTENANCE 


COST 

DATE 

Type 

Numeric 

Date 

Length 

7,2 

8 

Picture 

Z, ZZZ, ZZ9.99 

Z9/99/9999 

Notes 


The NEXT PREVENTIVE 
MAINTENANCE DATE is 
calculated by adding the MA1 
TENANCEINTERVAL to th 

LAST PREVENTIVE 

MAINTENANCE DATE. 

Ñame 

PHONE NUMBER 

REPAIR STATUS 

Type 

Character 

Character 

Length 

7 

1 

Picture 

999-9999 

X 

Notes 


Table of codes: Repair Table 

Default 


C 


|g¡§ E-22. Use la características Repository Reports para producir los siguientes informes y ma¬ 
trices, ya sea imprimiendo los informes o viéndolos mediante su navegador Web. Los 
criterios de selección del cuadro de diálogo Repository Reports se listan, separados 
con una diagonal {/]. Explique en un párrafo en dónde se podría usar eficazmente la 
información producida. 

a. Data Flow/Cross-Reference Listing/Data Element/Entire Project 

b. Data Flow/Cross-Reference Listing/Data Structure/Entire Project 

c. Record Contains Element (One Level] Matrix 

d. Data Flow/Single-Entry Listing/Software Master—Normalized 
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€§# E-23. 


E-24. 



e. Data Flow/Diagram Location Matrix/Data Stores versus Diagrams 

f. Data Flow/Composition Matrix/Data Elements versus Data Flows 

g. Data Flow/Composition Matrix/Data Elements versus Data Structures 

h. Data Flow/Composition Matrix/Data Element versus Data Stores 

Use la característica de Report Query para producir los informes siguientes. Explique 
en una frase qué información se le proporciona con el informe. 

a. El informe Undefined Elements 

b. El informe Elements without Pictures 

c. El informe Coded Elements 

d. El informe Any ítem with Components 

Imprima un informe de resumen para todos los componentes de flujo de datos que no 
tienen una descripción. /Sugerencia: Haga clic en el botón de opción No descriptive 
info.) 

Imprima un informe de resumen para todos los componentes de flujo de datos que 
no estén en un diagrama. [Sugerencia: Haga clic en el botón de opción No Location 
References.) 

. Imprima un informe detallado para todos los elementos. Incluya sólo la información 
física y los valores y significados. [Sugerencia: Haga clic en el botón Fields y después 
en el botón Invert y seleccione los campos que desee imprimir.) ¿Por qué seria útil 
este informe para el analista? 
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DESCRIPCIÓN DE LAS 
ESPECIFICACIONES 
DE PROCESOS Y DECISIONES 
ESTRUCTURADAS 


I 




OBJETIVOS DE APRENDIZAJE. , ; : 

Una vez que haya dominado el material de este capítulo, podrá: 

: 1. Entender el propósito de las especificaciones de procesos. 

2. Reconocer la diferencia entre decisiones estructuradas y semiestructuradas. 

3. Usar Español estructurado, tablas de decisión y árboles de decisión para analizar, describir 
y documentar decisiones estructuradas. 

4. Elegir un método de análisis de decisiones apropiado para analizar decisiones estructuradas 
y crear especificaciones de procesos. 


El analista de sistemas que aborda las especificaciones de procesos y las decisiones osirüclii- 
radas tiene muchas opciones para documentarlas y analizarlas. En los r capítulos.7 y H usted, 
vio procesos; como; VERIFICAR Y CALCULAR CUOTAS, pero.no se le e\pIiiji l:i Iónica 
necesaria para ejecutar estas tareas i Los métodos disponibles para documentar y analizar la 
lógica de las decisiones incluyen Español estructurado, tablas de decisión y arbole»¿ do deci¬ 
sión'. Es importante contar con Ía : capacidad de identificar la lógica y las decisiones estn.ite;; V 
turadas' qué ocurren en un negocio y cómo se distinguen de las decisiones scniii-slriict:LinF 
das. También es importante reconocer que las decisiones estructuradas son particularmente 
adecuadas para el análisis con métodos sistemáticos que promueven la cqmpletjifid, la 
exactitud y la comunicación. 


PANORAMA GENERAL DE LAS ESPECIFICACIONES DE PROCESOS 

Para determinar los requerimientos de información de una estrategia de análisis di- decisión, 
el analista de sistemas primero debe determinar los objetivos organizacionales medianil 1 , un: 
enfoque de jerarquización de arriba hacia abajo. El analista de sistemas dene entender los 
principios organizacionales y debe contar con experiencia en las técnicas de recopilación cíe 
datos. EJ enfoque de jerarquización de arriba hacia abajo es muy importante poi"iliie todas 
las décisiones de la organización se deben relacionar, por lo menos indirectamente, con los 
objetivos generales de la misma.: 

•: Las •especificaciones de procesos —a veces llamadas miniesperífwacÜmes, déhido a que 
representan una parte pequeña de las especificaciones del proyecto total—se crean parados 
procesos primitivos en un diagrama de flujo de datos así como también para algunos proco- 

































sos de nivel superior que se amplían a un diagrama hijo. Estas especificaciones explican la 
lógica de la toma de decisiones y las fórmulas que transformarán los datos de entrada de un 
proceso en salidas. Cada elemento derivado debe tener lógica del proceso para mostrar có¬ 
mo se origina de los elementos base u otros elementos derivados previamente creados que 
se alimentan del proceso primitivo. 

Las tres metas para producir especificaciones de procesos son las siguientes: 

1. Reducir la ambigüedad del proceso. Esta meta obliga al analista a aprender los detalles 
acerca del funcionamiento de un proceso. Es necesario detectar, anotar e integrar las 
áreas indefinidas de todas las especificaciones de procesos. Estas observaciones consti¬ 
tuyen una base y proporcionan las preguntas para las entrevistas de seguimiento con la 
comunidad de usuarios. 

2. Obtener una descripción precisa de lo que se está realizando, lo cual normalmente se 
incluye en un paquete de especificaciones para el programador. 

3. Validar el diseño del sistema. Esta meta incluye garantizar que un proceso tenga todo el 
flujo de datos de entrada necesario para producir la salida. Además, todas las entradas y 
salidas deben representarse en el diagrama de flujo de datos. 

Usted encontrará muchas situaciones en las que no se crean especificaciones de proce¬ 
sos. A veces el proceso es muy simple o el código de la computadora ya existe. Esta even¬ 
tualidad se debería asentar en la descripción del proceso, y no se requeriría ningún diseño 
adicional. A continuación se mencionan las categorías de procesos que generalmente no re¬ 
quieren especificaciones: 

1. Procesos que representan entrada o salida física, tal como leer y escribir. Por lo general 
estos procesos sólo requieren lógica simple. 

2. Procesos que representan una validación de datos simple, la cual normalmente es bas¬ 
tante fácil de realizar. Los criterios de edición se incluyen en el diccionario de datos y se 
integran en el código fuente de la computadora. Las especificaciones de procesos se po¬ 
drían crear para la edición compleja. 

3. Procesos que usen código preescrito. Estos procesos generalmente se incluyen en un 
sistema como subprogramas y funciones. 

Los subprogramas son programas de computadora que se escriben, prueban y almace¬ 
nan en el sistema de cómputo. Estos normalmente realizan una función general en el siste¬ 
ma, tal como validar una fecha o un dígito de verificación. Estos subprogramas de propósito 
general se escriben y documentan una sola vez pero constituyen una serie de elementos 
esenciales que se podrían usar en muchos sistemas en toda la organización. Por lo tanto, di¬ 
chos subprogramas aparecen como procesos en muchos diagramas de flujo de datos. Las 
funciones son semejantes a los subprogramas pero se codifican de forma distinta. 


FORMATO DE LA ESPECIFICACIÓN DE PROCESOS 


Como se demuestra en la figura 9.1, las especificaciones de procesos vinculan el proceso al 
diagrama de flujo de datos y, por consiguiente, al diccionario de datos. La especificación de 
cada proceso se debe registrar en un formulario especial o en la pantalla de una herramien¬ 
ta CASE como la que utiliza Visible Analyst y que se muestra en el caso de la CPU al final 
de este capítulo. Teclee la siguiente información: 


1. El número del proceso, el cual debe coincidir con el ID del proceso del diagrama de flu¬ 
jo de datos. Esta especificación permite a un analista trabajar con cualquier proceso o 
modificarlo y localizar fácilmente el diagrama de flujo de datos donde se encuentra el 
proceso. 

2. El nombre del proceso, el cual nuevamente debe ser el mismo que el asentado en el sím¬ 
bolo del proceso en el diagrama de flujo de datos. 

3. Una descripción breve de lo que realiza el proceso. 
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Diagrama de flujo de datos Especificaciones y lógica del proceso 




£c,vtü ■ relacionan las 
especificaciones :.'a' proceso 

con el diagrama de flujo de datos. 


4. Una lista de flujos de datos de entrada, usando los nombres que están en-el diagrama de 
flujo de datos. Los nombres de datos que se usan en la fórmula o lógica deben coincidir 
con los del diccionario de datos para garantizar la consistencia y una buena comunicación. 

5. Los flujos de datos de salida, utilizando también los nombres del diagrama de flujo de 
datos y del diccionario de datos. 

6. Una indicación del tipo de proceso: por lote, en línea o manual. Todos los procesos en 
línea requieren diseños de pantalla, y todos los procesos manuales deben tener procedi¬ 
mientos bien definidos para que los empleados realicen las tareas del proceso. 

7. Si el proceso usa código preescrito, incluya el nombre del subprograma o función que 
conténga al código. 

8. Una descripción de la lógica del proceso que indique las políticas y reglas del negocio 
en lenguaje cotidiano, no en pseudocódigo de lenguaje de computadora. Las reglas del 
negocio son los procedimientos, o quizás un conjunto de condiciones o fórmulas, que 
permiten a una corporación dirigir su negocio. Los formatos comunes de las reglas del 
negocio incluyen lo siguiente: 

8 Definiciones de los términos del negocio. 

8 Condiciones y acciones del negocio. 

8 Restricciones de la integridad de los datos. 

e Derivaciones matemáticas y funcionales. 

8 Inferencias lógicas. 

8 Secuencias de procesamiento. 

• Relaciones entre las circunstancias del negocio. 

9. Si no hay suficiente espacio en el formulario para una descripción completa del Espa¬ 
ñol estructurado o si hay una tabla o árbol de decisión que describa la lógica, incluir el 
nombre de la tabla o árbol correspondiente. 

10. Mencione cualquier problema sin resolver, partes incompletas de la lógica u otras con¬ 
sideraciones. Estos problemas constituyen la base de las preguntas usadas para las en¬ 
trevistas de seguimiento. 

Los elementos anteriores se deben introducir para completar un formulario de especifica¬ 
ción del proceso, el cual contiene un número de proceso, nombre del proceso, o ambos, del 
diagrama de flujo de datos, así como también los otros ocho elementos que se muestran en 
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tjempío de un formulario 
contestado de especificaciones 
del proceso para determinar si 
un artículo está disponible. 


el ejemplo de World's Trend (figura 9.2). Observe que completar este formulario facilita 
ampliamente la vinculación del proceso con el diagrama de flujo de datos y el diccionario 
de datos. Cuando se usa un formulario electrónico, tal como las pantallas de Visible Analyst 
que se muestran en la figura 9.3, la descripción se registra en un área de desplazamiento. El 
botón Expand (Ampliar) permite al analista desplegar una gran cantidad de texto, que ayu¬ 
da a ver la lógica global del proceso. 


ESPAÑOL ESTRUCTURADO 

Cuando la lógica del proceso involucra fórmulas o iteración, o cuando las decisiones estruc¬ 
turadas no son complejas, el uso del Español estructurado es una técnica apropiada para 
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i-' 0 "' j nt n : 

Í Determine»an ítem ¡s available for sale. If it is not. créate a backordered 
ítem record Determine the Quantity available. 

IF the Order ítem Quantitj) is greater than the Quantitj* On Hand ■». | 

TFIEN Move Order Itern QuantltjJ to Available Ítem Quantítj! 

Move Order ítem Number to Available ítem Number 

ELSE 

Subtract Quantitji On Fland Irom Order ítem Quantítji 

gívmg Quantitj' Backordered LAM' 

Move Quantitji Backordered to Backordered ítem Record 
Move ítem Number to Backordered ítem Record 
DOWriteBackorderedRecord 
Move Quantitji On Hand to Available ítem Quantitji 
Move Order ítem Number to Available ítem Number 


. Notes:. Av;, Unresolved issues: Should the arnount that is on order tor thís itern be afe 
taken into account 7 Would this. combmed with the expected arrival date j” t 
íSSSpípiSí of goods on order change how the quantity available is calculated 7 


Long'Ñame' 


SQL Pelee [ Ne -:1 j fj EÍÍjl lSe;Trcj| ‘ j j J^mp ( Oftíe j i ■■■ Histsijf A 7 L A 

D;aíei . : Otear jYior[ Exit 'j j'Expand \ 3act Cgpii Search gritería- 
Press F1 lorHelp. , : L r ' ‘ ■ ai r„ " ! ■ 


FIGURAS 


Visible Analyst se puede utilizar 
para describir especificaciones 
de proceses. 


analizar el proceso de decisión. Como su nombre implica, el Español estructurado se basa 
en [1] lógica estructurada o instrucciones organizadas en procedimientos anidados y agru¬ 
pados, y (2) enunciados simples del Español tales como sumar, multiplicar y mover. 

Un problema de expresión se puede transformar en Español estructurado, poniendo las 
reglas de decisión en su secuencia adecuada y usando en todo momento la convención de 
instrucciones IF-THEN-ELSE. Como se muestra en la figura 9.4, el Español estructura¬ 
do puede ser más complejo si se anidan bloques de instrucciones dentro de otros bloques de 
instrucciones. 


CÓMO ESCRIBIR ESPAÑOL ESTRUCTURADO 

Para escribir Español estructurado, podría seguir las convenciones siguientes: 

1. Exprese toda la lógica en uno de estos cuatro tipos: estructuras secuenciales, estructu¬ 
ras de decisión, estructuras de caso o iteraciones (véanse los ejemplos de la figura 9.5). 

2. Use en mayúsculas las palabras clave aceptadas como IF, THEN, ELSE, DO, DO WHI- 
LE, DO UNTIL y PERFORM. 

3. Ponga sangría en los bloques de enunciados para mostrar claramente su jerarquía (ani- 
damiento). 

4. Cuando las palabras o frases se han definido en un diccionario de datos (como en el ca¬ 
pítulo 8], subráyelas para denotar que tienen un significado especializado o reservado. 

5. Tenga cuidado al usar "y" y "o", y evite la confusión al distinguir entre "mayor que" y 
"mayor que o igual a" y otras relaciones similares. "A y B" quiere decir tanto A como B; 
"A o B" quiere decir cualquiera de A o B, pero no ambos. Aclare ahora los enunciados 
lógicos en lugar de esperar hasta la etapa de codificación del programa. 
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MOLDEAMIENTO DE LA ESTRUCTURA 


Kozi se ha portado a la altura de las circunstancias y respondió las pre¬ 
guntas que usted le planteó en relación con ía política de manejo de los 
pedidos pendientes en Kocl-Naz, Inc. Con base en las respuestas de Kozi y 
en las suposiciones que usted considere necesarias, vacíe en un nuevo 


molde lo que Kozi le dijo (en la Oportunidad de consultpríá 9.1) y reescriba 
en Español estructurado la receta para el manejo de los pedidos pendien¬ 
tes. En un párrafo, describa cómo podría cambiar este proceso si utilizara 
el correo electrónico para enviar los avisos en vez del correo tradicional. 


mos si un solicitante tiene póliza A o póliza B, las cuales difieren en los deducibles 
y copagos (el porcentaje de los gastos que deben cubrir los solicitantes]. Para am¬ 
bas pólizas, verificamos si se ha cubierto el deducible ($100 para el plan A y $50 
para el plan B). Si no se ha cubierto el deducible, se lo restamos al reembolso. Para 
ajustar el copago seguimos otro paso; restamos al reembolso el porcentaje de los 
gastos que el solicitante debe pagar (40 por ciento para el plan A y 60 por ciento 
para el plan B). Por último expedimos un cheque si le corresponde alguna cantidad 
al solicitante, imprimimos un resumen de la transacción y actualizamos nuestras 
cuentas. Esto lo hacemos hasta que se procesan todas las solicitudes de reembolso 
del día. 

Al examinar los enunciados anteriores, es posible observar algunas estructuras de secuencia 
simple, particularmente al principio y al final. Hay un par de estructuras de decisión, y es 
más conveniente anidarlas, determinando primero qué plan (A o B] usar y después restan¬ 
do los deducibles y copagos correctos. La última declaración apunta a una iteración: con 
DO UNTIL hasta que se procesen todas las solicitudes de reembolso o con DO WHILE si 
aún hay solicitudes de reembolso pendientes. 

Con base en el hecho de que es posible anidar las estructuras de decisión según los pla¬ 
nes de las pólizas, podemos escribir el Español estructurado para el ejemplo anterior (véase 


Tipo de Español estructurado 

Estructura secuencial 
Un bloque de instrucciones en el 
cual: no ocurren, bifurcaciones 


Estructura de decisión 
Sólo IF una condición es verdadera, 
complete las siguientes instrucciones; 
de otra manera, pase al ELSE 


Ejemplo 

Acción #1, 
Acción. #2, 
Acción.#3 


IF la condición A es verdadera 
THEN implementar la acción A 
ELSE implementar la acción B 
ENDIF 


E er ¡pk c c re ‘ágicrj t x Meca val 
ivn ua esu'jcx v.t .icvíV',. . 
una estructura de decisión, ünn 
estructura de caso y una iteraciúq. 


Estructura de caso ■ 1 : . IF Case #1 implementar acción #1 

•• Un tipo especial de estructura ' • ELSE: IFCaso#2 . ;v,;;: 1 

-. de decisión en el cual los casos ._ 'Implementar.acción. #2 

: son mutuamente excluyentes , ELSE IFCase#3 

. (si ocurre uno. los otros no Implementar acción #3 

' rl, mrlrtñ , rVlrW,. I : v- .-I-’- ELSE" I FCaSC#4 ! : ! • 


pueden ocurrir) 


Implementar acción #4A((r j 
• .. . ELSE mDri^ir error. A 


Iteración 

Bloques de instrucciones que se 
repiten hasta que se completan 


DO WHILE haya clientes. 

Acción #í 

ENDDO 
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Español estructurado para el 
sistema de procesamiento 
de solicitudes de reembolso de 
gastos médicos. Los términos 
subrayados significan que estos 
últimos se han definido en el 
diccionario de datos. 


maná». 

¿Sssssssr—* 

THEwitr Ü a i CUbím ° 611 feíWe de $100.00 

7^¿^**m**m 

ELSE continuar 
ENDIF 

Restar al reembolso 40% de c O p a g 0 

« citante tiene plan de la póliza 8 
THFfii í a , cub ' ert óeT^ciblede"$50.00 
Actualizar deducibf^ * 

ELSE continuar 
ENDIF 

Resür al reembolso 60% de copago 
ELSE continuar 

ENDIF eSCríbÍr 

ENDIF 

IF-ceembolso es mayor que cero 
Imprimir c heque 
EWDIF 

Imprimir resumen para el solicitante 
Actualizar cuentas- 






la figura 9.6]. Conforme empiece a trabajar en el Español estructurado, encontrará que par¬ 
te de la lógica y las relaciones que antes parecían claras en realidad son ambiguas. Por ejem¬ 
plo, ¿agregamos la solicitud de reembolso a las solicitudes realizadas hasta la fecha (RHF) 
antes o después de actualizar el deducible? ¿Es posible que ocurra un error si se almacena 
algo diferente al plan A o B en el registro del solicitante? ¿Restamos 40 por ciento de qué a 
la solicitud de reembolso? Estas ambigüedades se deben aclarar en este momento. 

Además de la ventaja obvia de aclarar la lógica y las relaciones que tienen los lenguajes 
humanos, el Español estructurado cuenta con otra ventaja importante: es una herramienta 
de comunicación. El Español estructurado se puede enseñar a otros miembros de la organi¬ 
zación, de manera que si la comunicación es importante, el Español estructurado es una al¬ 
ternativa viable para el análisis de decisión. 


DICCIONARIO DE DATOS Y ESPECIFICACIONES DE PROCESOS 

Todos los programas de computadora se podrían codificar mediante tres estructuras básicas: 
secuencia, selección (IE..THEN... ELSE y la estructura de casos) e iteración o ciclos. El dic¬ 
cionario de datos indica cuál de estas estructuras se debe incluir en las especificaciones del 
proceso. 


29b s .,} r& wr‘ j 
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Notificación de envío = 


Nombre del cliente = 


Dirección = 


Número del pedido - 
Fecha del pedido - 
Número del cliente + 

Nombre del cliente+ 
p.rección del cliente • \ 

£ e a s A artículo A ! pedido},: 
Numero de artículos+ : 

Total de mercancías - 
(Impuesto) + 

Gastos de envío - 
Total del pedido 

Nombre 


Líneas de artículo 
del pedido = 



(Departamento) 
Ciudad 
Estadoí 
Código postal 

(Expansión 
(País) 


del código postal) 


Número de artículo + 
Cantidad pedida + 

Cantidad por reabastecer+ 
Descripción del artículo + 
Descripción del tamaño + 
Descripción del color + 
Precio unitario 
Cantidad extendida 


Estructura de datos para una 
notificación de envío de 
World's Trend. ' ■ 


Si el diccionario de datos para el flujo de datos de entrada y salida contiene una serie 
de campos sin ninguna iteración —{ }— o selección —[ ]— la especificación del proceso 
contendrá una secuencia simple de instrucciones, como MOVER, SUMAR y RESTAR. 
Consulte el ejemplo que se ilustra en la figura 9.7 de un diccionario de datos para la NO¬ 
TIFICACIÓN DE ENVÍO. Observe que el diccionario de datos para la NOTIFICACIÓN 
DE ENVÍO tiene como campos secuenciales simples el NUMERO DEL PEDIDO, FE¬ 
CHA DEL PEDIDO y NUMERO DEL CLIENTE. La lógica correspondiente, mostrada 
en las líneas 3 a 5 en el Español estructurado de la figura 9.8, consiste en enunciados MO¬ 
VER simples. 

Una estructura de datos con elementos opcionales encerrados entre paréntesis y/o en¬ 
cerrados entre corchetes tendrá una instrucción IF... THEN... ELSE correspondiente en la 
especificación del proceso. Asimismo, si una cantidad, como la CANTIDAD POR REA¬ 
BASTECER, es mayor que cero, la lógica subyacente será IF... THEN... ELSE. La iteración, 
indicada mediante llaves en una estructura de datos, debe tener un DO WHILE, DO UNTIL 
o PERFORM UNTIL correspondiente para controlar el ciclo en la especificación del proce¬ 
so. La estructura de datos para las LÍNEAS DE ARTÍCULO DEL PEDIDO permite hasta 
cinco artículos en el ciclo. Las líneas 8 a 17 muestran las instrucciones contenidas en el DO 
WHILE hasta el END DO necesarias para producir las múltiples LÍNEAS DE ARTÍCU¬ 
LO DEL PEDIDO. 
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Español estructurado para 
crear la notificación de envío 
de World's Trend. 


fepaftol eslfunllrrarii. 


^ envío. Después de dar formato a cada línea de la notificación, 


1. 

2 . 

3. 

4. 

5. 

6. 

7. 

8 . 


GET Registro del pedido 
6ET Registro del cliente 


Mueva el -Múma m-del pedido a la Molificación de envío 
Mueva la Eenha del pedido a la Molificación de énvto— 

Mueva el Ntfflwo del diento a laNotiticacion de énvto 

(deje un solo espacio entre Nombre/Segundo 


m. 

11. 

12 . 

13. 

14. 

15. 

16. 

17. 

18. 

19. 

20 . 

21 . 

22 . 

23. 

24. 

25. 

26. 

27. 


DO formatee las líneas de Dirección del cliente 
DO WHILE haya artículos paralípedido 
GET Registro del artícul o 
DO formatee la Línea del articulo 

illque el-ñráuuijlarip por la Cantidad pedida para obtener 
ligad extendida -—_ 


Mueva la Santidad-ext endida a las Líneas de artículo del pedido 

Sume GafltidacLe xlendida al Total delaTmercSncías- 

IF la Canti dad ñor reahasteceT eTmavñniürcHro— 

END||Mueva la Cantidad pnr mahasfurer a las Líneas de artículo del pedido 


ENDDO 

Mueva el Total H ° m£ican£Ías Q la Notificación de envío 
Mueva 0 al impuesto 
IF Estada es ¡guala CT 




Multiplicar el Totel-óe-mefcandas por la Tasa de impuesto para obtener el Impuesto 
ENDIF ~ — _____ 

Mueva el impuesto-a la Notificación de envío 
DO calcular Ga.^tns He envío 
Mueva instes de envío a la Notificación de envío 

Sume IotaLd £ mercancías , impuesto y Gastos ae envío para obtener el Total del pedido 
Mueva Total deLpedids a la MotiflcaclónTle erivícr- . 


TABLAS DE DECISIÓN 


Como se muestra en la figura 9.9, una tabla de decisión es una tabla de filas y columnas se¬ 
paradas en cuatro cuadrantes. El cuadrante superior izquierdo contiene la(s) condición(es); 
el cuadrante superior derecho contiene las alternativas de condición. En la parte inferior iz¬ 
quierda de la tabla se encuentran las acciones que se deben realizar y en la parte inferior 



Formato estándar usado para 
presentar una tabla de decisión. 


Condiciones y acciones Reglas 


Condiciones 


Alíématlvás tdé condición 


Acciones 


Entradas de acción 










Condiciones y acciones 


Reglas 

1 2 3 4 

Menor de $50 - -■ p S ; ,N N • 

Paga con cheque con dos formas do ID S N S N 

Usa tarjeta de crédito . . N S • ,N ' S ! 

Registrar una venta X 

Buscar tarjeta de crédito en el libro X 

Pedir aprobación al supervisor X 

Pedir autorización de la tarjeta al banco X 



:üsa js Lita tabia de ceastón . 

íjuiL? iiiiSirüt't'jistsiüftiuir o** lo 

tienda sobre el pago del cliente 
con cuatro grupos de reglas y 
cuatro acciones posibles. 


derecha las reglas para llevar a cabo las acciones. Cuando se usa una tabla de decisión pa¬ 
ra determinar qué acción se debe realizar, la lógica se mueve en el sentido de las manecillas 
del reloj empezando en la parte superior izquierda. 

Suponga que una tienda desea ilustrar su política sobre las compras que los clientes no 
pagan en efectivo. Como se muestra en la figura 9.10, la compañía podría hacer esto me¬ 
diante una sencilla tabla de decisión. Cada una de las tres condiciones (venta menor de $50, 
paga con cheque y usa tarjeta de crédito) tiene tan sólo dos alternativas. Las dos alternativas 
son S (sí, es verdad) o N (no, no es verdad). Pueden ocurrir cuatro acciones: 

1. Registrar la venta. 

2. Buscar el número de la tarjeta de crédito en el libro antes de registrar la venta. 

3. Pedir la aprobación al supervisor. 

4. Pedir la autorización de la tarjeta de crédito al banco. 

El último ingrediente que hace que la tabla de decisión valga la pena es el grupo de re¬ 
glas para cada una de las acciones. Las reglas son las combinaciones de las alternativas de 
condición que provocan una acción. Por ejemplo, la regla 3 dice: 

IF N (la venta total NO es menor a $50.00) 

AND 

IF S (el cliente pagó con cheque y presentó dos formas de ID) 

AND 

IF N (el cliente no usó una tarjeta de crédito) 

THEN 

DO X (pedir la aprobación al supervisor). 

El ejemplo anterior presentó un problema con cuatro grupos de reglas y cuatro accio¬ 
nes posibles, pero sólo es una coincidencia. El próximo ejemplo demuestra que las tablas de 
decisión con frecuencia se hacen más grandes y complejas. 


DESARROLLO DE TABLAS DE DECISIÓN 

Para construir tablas de decisión, el analista necesita determinar el tamaño máximo de la ta¬ 
bla; eliminar situaciones imposibles, inconsistencias o redundancias, y simplificar la tabla 
tanto como sea posible. Los pasos siguientes proporcionan al analista un método sistemáti¬ 
co para desarrollar tablas de decisión: 

1. Determine el número de condiciones que podrían afectar la decisión. Combine filas 
que se traslapen, como en el caso de condiciones que se excluyen mutuamente. El nú¬ 
mero de condiciones se vuelve el número de filas en la mitad superior de la tabla de 
decisión. 

2. Determine el número de posibles acciones que se pueden realizar. Dicho número se 
vuelve el número de filas en la mitad inferior de la tabla de decisión. 

3. Determine el número de alternativas de condición para cada condición. En la forma 
más simple de tabla de decisión, habría dos alternativas (S o N) para cada condición. 
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En una tabla de entradas extendidas podría haber muchas alternativas para cada 
condición. 

4. Calcule el número máximo de columnas en la tabla de decisión multiplicando el nú¬ 
mero de alternativas para cada condición. Si hubiera cuatro condiciones y dos alterna¬ 
tivas (S o N) para cada una de las condiciones, habría 16 posibilidades como sigue: 

Condición 1: x 2 alternativas 
Condición 2: x 2 alternativas 
Condición 3: x 2 alternativas 
Condición 4: x 2 alternativas 
16 posibilidades 


5. Complete las alternativas de condición. Empiece con la primera condición y divida el 
número de columnas entre el número de alternativas para esa condición. En el ejem¬ 
plo anterior hay 16 columnas y dos alternativas (S o N], de modo que 16 dividido en¬ 
tre 2 es 8. Después seleccione una de las alternativas, supongamos S, y escríbala en las 
primeras ocho columnas. Termine escribiendo N en las ocho columnas restantes como 
sigue: 


Condición 1: SSSSSSSSNNNNNNNN 


Repita este paso para cada condición mediante un subconjunto de la tabla. 


Condición 1: SSSSSSSSNNNNNNNN 


Condición 2: 
Condición 3: 
Condición 4: 


SSSSNNNN 
S S N N 
S N 


y siga el patrón para cada condición: 


Condición 1: 
Condición 2: 
Condición 3 : 
Condición 4: 


SSSSSSSSNNNNNNNN 
SSSSNNNNSSSSNNNN 
SSNNS SNNS SNNS SNN 
SNSNSNSNSNSNSNSN 


6. Complete la tabla insertando una X en donde las reglas indiquen ciertas acciones. 

7. Combine las reglas en donde sea evidente que una alternativa no representa una dife¬ 
rencia en el resultado. Por ejemplo, 


Condición 1: S S 

Condición 2: S N 

Acción 1: XX 


se puede expresar como: 


Condición 1: S 

Condición 2: — 

Acción 1: X 

La raya [—] significa que la condición 2 puede ser S o N, y que aún así se realizará la 
acción. 
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rsw OPORTUNIDAD DE CQNSüLTQRÍA 9.3 


AH O R ROS EN LARÍNIADEAUIQMÓVILES DE CITRÓN 


."Nos sentimos afortunados de ser tan populares. Creo que los clien¬ 
tes piensan que tenemos tantas opciones para ofrecer que se sienten 
obligados a rentar alguno de nuestros automóviles”, dice Ricardo Limón, 
quien maneja varias sucursales de Citrón Car Rental. "Nuestro.lema es. 
'Usted nunca se sentirá apretado en Citrón'. Tenemos cinco tamaños de 
automóviles que clasificamos de la A a la E 

:■ Ai; SubcompactO:j v ;Ly--.;L-; : T^=;¡_r / . Ljv;;; 

j.:B ‘b Cómpacióvt: v;c .' ' ■ . 

C Mediano 

D[:;Grandéf;;:^ ó ~’y V LCL Y •„ 

"La transmisión estándar sólo está disponible para A. B y C,. La 
transmisión automática está disponible para todos los automóviles"; 

"Si un cliente reserva un subcompacto (A) y al llegar aquí no tenemos 
uno. ese cliente tiene derecho a una actualización gratuita al automóvil 
del siguiente tamaño, en este caso un compacto (B). Los clientes tam¬ 
bién reciben una actualización gratuita del tamaño de su automóvil re¬ 


servado si su compañía tiene una cuenta con nosotros. Asimismo, hay un 
descuento en la membresía de cualquiera de los clubes de viajero fre¬ 
cuente administrados por las aerolíneas que cooperan con nosotros. 
Cuando los clientes llegan al mostrador, nos indican el tamaño del auto¬ 
móvil que reservaron, y entonces verificamos si lo tenemos listo para que 
se lo lleven. Por lo general mencionan si tienen algún descuento, y noso¬ 
tros les preguntamos si quieren seguro y cuánto tiempo usarán el auto¬ 
móvil. A continuación, calculamos su tasa y redactamos un listado para 
que lo firmen en ese momento”. 

Ricardo le ha pedido que computarice el proceso de facturación de 
Citrón para que los clientes puedan conseguir sus automóviles con rapi¬ 
dez y se les.facture sin errores. Dibuje una tabla de decisión que repre¬ 
sente las condiciones, alternativas de condición, acciones y reglas de 
acción que haya deducido de la descripción de Ricardo y con las cuales 
podrá generar un proceso de facturación automatizado/. 

Ricardo está considerando hacer posible la reservación de automóviles 
a través de la Web. Dibuje una tabla de decisión actualizada que muestre 
un descuento de 10 por ciento por reservar un automóvil en la Web. 


8. Verifique si la tabla contiene situaciones imposibles, contradicciones y redundancias. 
Éstas se discuten posteriormente con más detalle. 

9. Reorganice las condiciones y acciones (o incluso las reglas) si esto hace más comprensi¬ 
ble la tabla de decisión. 

Ejemplo de una tabla de decisión La figura 9.11 es un ejemplo de una tabla de decisión 
desarrollada mediante los pasos recién descritos. En este ejemplo una compañía está inten¬ 
tando mantener una lista de correo significativa de clientes. El objetivo es mandar única¬ 
mente los catálogos de los cuales los clientes comprarán la mercancía. 

La compañía está consciente de que ciertos clientes leales piden de cada catálogo y que 
algunas personas de la lista de correo nunca hacen un pedido. Estos patrones de pedido son 
fáciles de observar, pero es más difícil decidir cuáles catálogos enviar a los clientes que sólo 
piden de catálogos seleccionados. Una vez que se toman estas decisiones, se construye una 
tabla de decisión para tres condiciones (Cl; el cliente hizo un pedido del catálogo de Oto¬ 
ño; C2: el cliente hizo un pedido del catálogo de Navidad, y C3: el cliente hizo un pedido 
del catálogo de especialidad), con dos alternativas para cada una (S o N). Se pueden realizar 
tres acciones (Al: mandar el catálogo de Navidad de este año; A2: mandar el nuevo catálo- 


Reglas 


Condiciones y acciones 


El cliente hizo un-pedidodel catalogo de Otoño - - S S S “ -S N 

El cliente hizct uit pedido-del catalogo de Navidad S S. N - N S 

E' c e"te h'zc un pedido delcatálogol de especialidad :-/ ¿ N 3 N S 

Mandar e!.catálogo de Navidad de este añp X X. 

Mandar el catálogo de especialidad . X 

Mandar amoos catálogos ' . X X, ■ 


N N N 

-s:-/ ánl n í 


Construcción de unatabla de 
decisión para dedidir qué. 

;. catálogo enviar al cliente que 
: pide únicamente de catálogos 
seleccionados/vví:<-: ''.b-fyb 
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Combinación de las reglas para 
simplificar la tabla de decisión 
del catálogo del cliente. 


Condiciones y acciones 1 

El cliente hizo un pedido dol catálogo de Otoño . S 

El cliente hizo un pedido del catálogo de Navidad S 

El cliente hizo un pedido del catálogo de especialidad S 

Mandar el catálogo de Navidad de este año 

Mandar el catálogo de especialidad 

Mandar ambos catálogos X 


3 

41 

_ 

Reglas 

5 

6 

7 

S 

S 

N 

N 

N 


k 

■T-'S... 

S 

N 

v s 

N 

¿ s ; 

N 

Y's; 

X 

X 

X 

X 

X 


Condiciones y acciones 

É| cliente hizó'un pedido el el catálogo de Otoño 
:;:EHeliéhte:hizQ:iinJpedidó:del catálogo de Navidad "•••¿ü 
El clien%hizO ijn);pedidojdél A catálogo de especialidad 

Mandar el catálogo de Navidad de este año 
Mandar el catálogo de especialidad 
Mandar ambos catálogos 


go de especialidad, y A3: mandar ambos catálogos). La tabla de decisión resultante tiene seis 
filas (tres condiciones y tres acciones) y ocho columnas (dos alternativas x dos alternativas 
x dos alternativas). 

A continuación se examina la tabla de decisión para determinar si se puede reducir. 
No hay condiciones mutuamente excluyentes, de modo que no es posible arreglárselas con 
menos de tres filas de condiciones. Ninguna regla permite la combinación de acciones. Sin 
embargo, como se muestra en la figura 9.12, es posible combinar algunas de las reglas. Por 
ejemplo, las reglas 2, 4, 6 y 8 se pueden combinar debido a que todas tienen dos cosas en 


1. Nos piden que mandemos el catálogo de Navidad de este año. 

2. La alternativa para la condición 3 siempre es N. 

No importa cuáles sean las alternativas para las primeras dos condiciones, de modo que es 
posible poner rayas [—] en lugar de S o N. 

Las reglas restantes —reglas 1, 3, 5 y 7— no se pueden reducir a una sola regla porque 
quedan dos acciones diferentes. En cambio, las reglas 1 y 5 se pueden combinar, lo mis¬ 
mo que las reglas 3 y 7. 


VERIFICACIÓN DE LA COiPLETITUD Y LA EXACTITUD 

Es esencial verificar que sus tablas de decisión estén completas y sean exactas. En el desarro¬ 
llo de las tablas de decisión pueden ocurrir cuatro problemas principales: incompletitud, si¬ 
tuaciones imposibles, contradicciones y redundancia. 

Es de suma importancia asegurarse de que todas las condiciones, alternativas de condi¬ 
ción, acciones y reglas de acción estén completas. Suponga que una condición importante 
—si un cliente pidió menos de $50— se ha omitido en el problema de la tienda de ventas 
por catálogo discutido anteriormente. La tabla de decisión entera cambiaría porque se ten¬ 
dría que agregar una nueva condición, un nuevo grupo de alternativas, una nueva acción y 
una o más reglas de acción. Suponga que la regla es: IF el cliente no pidió más de $50, 
THEN no enviar ningún catálogo. Como se muestra en la figura 9.13, se agregaría una nueva 
regla 4 en la tabla de decisión. 
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Reglas 


Condiciones y acciones V 2 1 3 1 4 1 

El cliente hizo un pedido del catálogo de Otoño/: . — y.' ■ 

El cliente hizo un pedido del catálogo de.Navidad o S : — ^ N^'v;:¡:;l: 

■ El cliente hlzo : un pedido del catálogo de especialidad ST:T¡t:TíTT: : :Ñ 
Pidió $50 o más • . ■ ■■■■ S S S N 

Mandar el catálogo de Navidad de este año X 

Mandar el catálogo de especialidad X 

Mandar ambos catálogos X 

No enviar ningún catálogo X 



La adición de una regla a la 
tabla de decisión del catálogo 
de clientes cambia toda la tabla. 


Al construir las tablas de decisión como se describió en los pasos anteriores, en ocasio¬ 
nes se establecen situaciones imposibles. En la figura 9.14 se muestra un ejemplo. La regla 1 
no es factible, debido a que una persona no puede ganar más de $50,000 por año y menos 
de $2,000 por mes al mismo tiempo. Las otras tres reglas son válidas. El problema pasa 
inadvertido porque la primera condición se midió en años y la segunda condición en meses. 

Las contradicciones ocurren cuando las reglas sugieren acciones diferentes pero satisfacen 
las mismas condiciones. La falla se podría deber a la forma’en que el analista haya construi¬ 
do la tabla o a la información que haya recibido. Las contradicciones ocurren con frecuen¬ 
cia si las rayas [—■] se insertan incorrectamente en la tabla. La redundancia ocurre cuando 
grupos idénticos de alternativas requieren exactamente la misma acción. En la figura 9.15 
se ilustra una contradicción y una redundancia. El analista debe determinar lo que es co¬ 
rrecto y resolver a continuación la contradicción o la redundancia. 


TABLAS DE DECISIÓN MÁS AVANZADAS 

Las tablas de decisión pueden ser muy difíciles de manejar porque crecen rápidamente con¬ 
forme se incrementa el número de condiciones y alternativas. Una tabla con tan sólo siete 
condiciones y con alternativas sí o no tendría 128 columnas. Para reducirla complejidad de 
las tablas de decisión difíciles de manejar, use entradas extendidas o la regla ELSE, o bien, 
construya varias tablas. 

Observe que en la siguiente tabla de S o N las condiciones son mutuamente excluyentes. 


Cl: 

No pidió 

S 

N 

N 

N 

C2: 

Pidió una vez 

N 

S 

N 

N 

C3: 

Pidió dos veces 

N 

N 

S 

N 

C4: 

Pidió más de dos veces 

N 

N 

N 

N 
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de decisión contiene situaciones 


imposibles. 
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Contradicción 


-UJLL 


Redundancia 


Por lo tanto, las condiciones se pueden escribir en forma de entradas extendidas como sigue: 

Cl: Número de veces que el cliente pidió 0 1 2 >2 

El número de columnas y filas requeridas disminuye y la comprensibilidad aumenta. En lu¬ 
gar de usar cuatro filas para el número de veces que pide un cliente, tan sólo se necesita una. 

En la figura 9.16 se muestra un ejemplo de política de pedidos estructurados con base 
en el inventario. El costo de un artículo puede ser menor que $10, entre $10 y $50, o 
mayor que $50. Además, la cantidad del pedido puede ser menor que 50 unidades por pe¬ 
dido, entre 50 y 100 unidades, o más de 100 unidades. La tabla de decisión sólo tiene dos 
filas de condición, y las alternativas se escriben con palabras en el cuadrante superior dere¬ 
cho. Al usar tablas de entradas extendidas, disminuye la probabilidad de redundancia y 
contradicción. 

El uso de la columna ELSE es otra técnica útil para construir tablas de decisión. Esta 
técnica es útil para eliminar muchas reglas repetitivas que requieren exactamente la misma 


■¡■■mi 

El uso de tablas de entradas 

Condiciones 
y acciones 

—1- - 2 

Reglas 

3 

4 

5 

6 

extendidas reduce la posibilidad 
de redundancia y contradicción. 

■ Costo . ; :.. A . 

'-'Menos» 

Entre 

Más 

Menos 


del artículo 

.o ? ; . A 7 -do $10 

$10y 

de $50, 

de ó 

7; ; :¡zde : -$50 


Cantidad pedida 

• Menos Entre 

$50 ' ■ . 

inclusive 

Entre 

Entre 

igual a 
$50 

X á. S 

Má s de 



de 50 50 y 100 

50 y 100 

50 y 100 

■ = dé 100/ 

7-: ;100 V : 



unidades unidades 

unidades 

unidades 

7 /.unidades 

i Unidades; 



■, inclusive 

; inclusive 

inclusive 




Pedir 

inmediatamente 


X 





Esperar hasta 
que se haga 

el pedido normal X X 

Verificar con 

el supervisor X X 

Enviara compra 

mediante oferta X 
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acción. También es útil para evitar omisiones. La figura 9.17 muestra cómo la política de pe¬ 
didos automáticos con base en el inventario se puede beneficiar de la regla ELSE. 

Las tablas de decisión son una herramienta importante en el análisis de decisiones es¬ 
tructuradas. Una ventaja importante de usar tablas de decisión en lugar de otros métodos 
es que éstas ayudan al analista a asegurar la completitud. Al usar tablas de decisión, también es 
fácil verificar posibles errores, tal como situaciones imposibles, contradicciones y redundan¬ 
cia. También existen prodesadores de tablas de decisión que toman la tabla como entrada y 
proporcionan código de programa de computadora como salida. 

ARBOLES DE DECISIÓN 

Los árboles de decisión se usan cuando ocurre una bifurcación compleja en un proceso de 
decisión estructurada. Los árboles también son útiles cuando es necesario mantener una 
cadena de decisiones en una secuencia particular. Aunque el nombre del árbol de decisión 
se deriva de los árboles naturales, en la mayoría de los casos los árboles de decisión se cons¬ 
truyen de manera lateral, con la raíz del árbol del lado izquierdo del papel; a partir de allí, 
el árbol extiende sus ramas hacia el lado derecho. Esta orientación permite al analista escri¬ 
bir en las ramas para describir condiciones y acciones. 

A diferencia del árbol de decisión que se utiliza en las ciencias administrativas, el árbol 
del analista no contiene probabilidades y resultados, debido a que en el análisis de sistemas 
los árboles se usan principalmente para identificar y organizar condiciones y acciones en un 
proceso de decisión completamente estructurado. 


CONSTRUCCIÓN DE ÁRBOLES DE DECISIÓN 

Es muy útil distinguir entre condiciones y acciones al dibujar árboles de decisión. Esta dis¬ 
tinción es especialmente significativa cuando las condiciones y acciones ocurren durante un 
periodo y su secuencia es importante. Para este propósito, use un nodo cuadrado para indi¬ 
car una acción y un círculo para representar una condición. El uso de notación hace al árbol 
de decisión más legible, como numerar los círculos y los cuadrados secuenciales. Considere 
que un círculo indica IF, mientras que un cuadrado representa THEN. 

Cuando se discutieron las tablas de decisión en una sección anterior, se usó el ejemplo 
de un punto de venta para determinar las acciones de aprobación de compra para una 
tienda departamental. Las condiciones incluyeron la cantidad de la venta (menor a $50) y 
si el cliente pagó con cheque o tarjeta de crédito. Las cuatro acciones posibles eran registrar 
la venta, buscar la tarjeta de crédito en un libro, pedir al supervisor la aprobación o pedir al 
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con más rapidez por los miembros de la organización. En consecuencia, son más apropiados 
como herramienta de comunicación. 


SELECCIÓN DE UNA TÉCNICA DE ANÁLISIS DE DECISIONES 
ESTRUCTURADAS 


Hemos examinado las tres técnicas para el análisis de decisiones estructuradas: Español es¬ 
tructurado, tablas de decisión y árboles de decisión. Aunque su uso no debe ser exclusivo, 
por lo general se elige una técnica de análisis para una decisión en lugar de usar las tres. Los 
siguientes lincamientos le proporcionan un método para escoger una de las tres técnicas pa¬ 
ra un caso particular: 


1. Use el Español estructurado cuando 

a. Haya muchas acciones repetitivas, 

O 

b. La comunicación con los usuarios finales sea importante. 



Ampliación del diagrama de 
flujo de datos del proceso 4, 
REGISTRO DE LA OFERTA 
DEL CUENTE. 
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2. Use tablas de decisión cuando 

a. Se encuentren combinaciones complejas de condiciones, acciones y reglas, 

O 

b. Requiera un método que evite eficazmente situaciones imposibles, redundancias y 
contradicciones. 

3. Use árboles de decisión cuando 

a. La secuencia de condiciones y acciones sea crítica, 

O 

b. Cuando no todas las condiciones sean relevantes para cada acción (las ramas son 
diferentes). 
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ESPECIFICACIMES'DIPROCESOFISICAS'Y LOGICAS 

Las secciones restantes de este capítulo son temas avanzados que usted puede explorar adi¬ 
cionalmente si lo desea. La primera sección muestra la manera en que un diagrama de flujo 
de datos se puede transformar en especificaciones del proceso. La segunda sección explica 
la manera en que se pueden usar a su vez las especificaciones del proceso para equilibrar (y 
corregir) un diagrama de flujo de datos. 

Cada proceso del diagrama de flujo de datos se puede ampliar a un diagrama hijo, un 
diagrama de estructura [discutida en el capítulo 16) o especificaciones del proceso [como 
Español estructurado). Si el proceso es primitivo, las especificaciones muestran la lógica, la 
aritmética o el algoritmo para transformar la entrada en salida. Estas especificaciones son 
parte del modelo lógico —las reglas del negocio— que existiría sin importar el tipo de siste¬ 
ma usado para implementar el negocio. Las reglas del negocio con frecuencia constituyen la 
base para crear un lenguaje de procedimientos al usar generadores de código. 

Por ejemplo, observamos que una casa de subasta tiene un sistema de cómputo para 
llevar un registro de las ofertas exitosas de un cliente [proceso 4) y para generar el estado 


i?:.;-» 
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de cuenta del proveedor del artículo subastado (proceso 3). Si el proceso se amplía a un 
diagrama hijo o un diagrama de estructura, la especificación del proceso describe el orden 
y condiciones bajo las cuales se ejecutarán los procesos del diagrama hijo. Esta lógica de con¬ 
trol es parte del modelo físico y se crearía después de haber determinado el método de im- 
plementación (ya sea por lotes o en línea) del proceso. La figura 9.19 muestra el Diagrama 4 
del sistema de subasta, una ampliación del proceso 4, REGISTRAR LA OFERTA DEL 
CLIENTE. Podemos tomar este DFD y expresar su lógica en Español estructurado como 
se muestra en el cuadro Lógica del proceso del formulario de especificación del proceso de 
la figura 9.20. 


USO DE LAS ESPECIFICACIONES DEL PROCESO: BALANCEO HORIZONTAL 

Las especificaciones del proceso, tanto en papel como capturadas mediante una herramien¬ 
ta CASE, se podrían usar para generar código fuente del lenguaje de cómputo y para anali¬ 
zar el diseño del sistema. Los programas de cómputo se indican mediante particionamiento 
en un diagrama de flujo de datos. Todas las especificaciones de proceso individuales para un 
programa se consolidan para convertirlas en los detalles del procesamiento en un paquete 
de especificaciones de programa. 

Al intentar redactar las especificaciones para un programa sin examinar cada proceso se 
podrían generar omisiones y errores. Debido a que las especificaciones del proceso se desa¬ 
rrollan a pequeña escala, un proceso a la vez, se podría analizar si la lógica de cada una está 
completa y es correcta. Cuando se termina el análisis y se hacen las correcciones a todos los 



Entradas del diccionario de 
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procesos de un programa, las especificaciones finales del programa deben estar completas y 
ser exactas. 

Las especificaciones del proceso se podrían usar para analizar el diagrama de flujo de 
datos y el diccionario de datos mediante un método llamado balanceo horizontal. El ba¬ 
lanceo horizontal especifica que todos los elementos del flujo de datos de salida se deben 
obtener de los elementos de entrada y de la lógica del proceso. Los elementos base en un 
flujo de datos de salida deben estar presentes en el flujo de entrada, y los elementos deriva¬ 
dos en un flujo de salida deben estar presentes en un flujo de datos de entrada o deben ser 
creados utilizando las especificaciones del proceso. Las áreas sin resolver se deben plantear 
como preguntas durante las entrevistas de seguimiento con los usuarios clave. 

Usaremos las siguientes figuras para mostrar cómo nos puede ayudar el Español estruc¬ 
turado a completar el diagrama de flujo de datos. La figura 9.21 ilustra el Diagrama 3, una 
ampliación incompleta del proceso 3 del SISTEMA DE LA SUBASTA, PRODUCIR ESTA¬ 
DO DE CUENTA DEL PROVEEDOR. La figura 9.22 muestra las entradas del diccionario 
de datos correspondientes. La figura 9.23 es el Español estructurado para el proceso 3.4, 
CALCULAR LA OFERTA NETA PARA EL PROVEEDOR, y para el proceso 3.5, IMPRI- 
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MIR LA LÍNEA DE LA OFERTA. La figura 9.24 es el Español estructurado para el proceso 
3.6. IMPRIMIR LA LÍNEA DEL TOTAL QUE SE LE DEBE PAGAR AL PROVEEDOR. 

La salida del proceso 3.4 es la OFERTA NETA para cada artículo, un elemento deriva¬ 
do. La lógica para el proceso requiere como entrada el TIPO DE PROVEEDOR y la CAN¬ 
TIDAD DE LA OFERTA DEL ARTÍCULO, ambos se usan en el cálculo de la OFERTA 
NETA. La verificación del diagrama de flujo de datos revela que estos dos elementos son 
entradas para el proceso 3.4. Sin embargo, sólo la OFERTA NETA se muestra como una sa¬ 
lida del proceso. La CANTIDAD PAGADA AL PROVEEDOR, incluida en la figura del Es¬ 
pañol estructurado, no se muestra en el diagrama de flujo de datos, ni el almacén de datos 
MAESTRO DE ARTÍCULOS. La OFERTA NETA REALIZADA HASTA LA FECHA no 
se incluye en el diccionario de datos para el REGISTRO DEL PROVEEDOR, ni tampoco se 
muestra en el diagrama de flujo de datos. El diagrama de flujo de datos y el diccionario de 
datos se deben actualizar para incluir estos componentes que faltan. La figura 9.25 muestra 
el Diagrama 3 con las correcciones necesarias. 

Examine la salida del proceso 3.5. La LÍNEA DEL ARTÍCULO DEL PROVEEDOR 
contiene cuatro elementos: DESCRIPCIÓN DEL ARTÍCULO, CANTIDAD OFRECIDA 
POR EL ARTÍCULO, OFERTA NETA y FECHA DE LA VENTA. La DESCRIPCIÓN DEL 
ARTÍCULO y la OFERTA NETA son entradas para el proceso 3.5, pero la FECHA DE LA 
VENTA y la CANTIDAD OFRECIDA POR EL ARTÍCULO, que son elementos base, no 
están en ningún flujo de entrada. Estos se deben agregar al diagrama de flujo de datos. Para 
evitar tener tres flujos de entrada [DESCRIPCIÓN DEL ARTÍCULO, CANTIDAD OFRE¬ 
CIDA POR EL ARTÍCULO y FECHA DE LA VENTA) yendo del proceso 3.2 al 3.3, todo 
el registro del artículo se pasa entre los dos procesos. El proceso final que se debe examinar 
es el 3.6. El Español estructurado requiere que el TIPO DE PROVEEDOR y la CANTI¬ 
DAD TOTAL DE LA OFERTA NETA estén presentes como flujos de entrada. Debido a 
que sólo está presente la CANTIDAD TOTAL DE LA OFERTA NETA, al proceso 3.6 le 
falta entrada. 
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Diagrama de flujo de datos 
corregido, una ampliación del 
proceso 3, Producir estado de 
cuenta del proveedor. 


RESUMEN 

Una vez que el analista identifica los flujos de datos y empieza a construir un diccionario de 
datos, es hora de pasar a la especificación de procesos y el análisis de decisión. Los tres mé¬ 
todos para el análisis de decisión y para describir la lógica del proceso descritos en este ca¬ 
pítulo, son Español estructurado, tablas de decisión y árboles de decisión. 

Las especificaciones de procesos (o miniespecificaciones) se crean para procesos primi¬ 
tivos de un diagrama de flujo de datos así como también para algunos procesos de alto nivel 
que se amplían a un diagrama hijo. Estas especificaciones explican la lógica de la toma de 
decisiones y las fórmulas que transformarán en salida los datos de entrada de un proceso. Los 
tres objetivos de la especificación de procesos son reducir la ambigüedad del proceso, obte¬ 
ner una descripción precisa de lo que se está realizando y validar el diseño del sistema. 
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"Es muy importante que usted haya podido pasar todo este tiempo con nosotros. Una cosa 
es segura, nosotros podemos usar la ayuda. Y evidentemente, de sus conversaciones con 
Snowden y otros, usted se habrá dado cuenta de que todos nosotros creemos que los consul¬ 
tores desempeñan un rol importante para ayudar a cambiar a las compañías. Bueno, de cual¬ 
quier manera la mayoría de nosotros así lo cree". 

"A veces la estructura es buena para una persona, o incluso una compañía. Como usted 
sabe, Snowden se interesa por cualquier tipo de estructura. Por eso algunas de las personas 
de Capacitación en ocasiones lo vuelven loco. Ellos son buenos para estructurar cosas para 
sus clientes, pero cuando se trata de organizar su propio trabajo, es otra historia. En fin, há¬ 
game saber si hay alguna foma en la que yo pueda ayudarlo". 


PREGUNTA DE HYPERCASE 

1. Astima que usted creará las especificaciones para un sistema automatizado de segui¬ 
miento de proyectos para los empleados de Capacitación. Una de las funciones del 
sistema será permitirle a los miembros del proyecto actualizar o agregar nombres, di¬ 
recciones, y números de teléfono y fax de nuevos clientes. Utilizando Español estructu¬ 
rado, escriba un procedimiento para llevar a cabo el proceso de introducir un nuevo 
nombre de cliente, dirección, y número de teléfono y fax. [Sugerencia: El procedimiento 
debe pedir un nombre de cliente, verificar si el nombre ya está en un archivo de clien¬ 
tes existente, y permitir al usuario validar y actualizar la dirección y números de teléfono 
y fax del cliente (si es necesario] o agregar la dirección de un nuevo cliente y sus núme¬ 
ros de teléfono y fax al archivo de clientes.] 
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Una gran parte del trabajo del analista de sistemas involucrará decisiones estructuradas, 
es decir, decisiones que pueden automatizarse si ocurren condiciones identificadas. Para ha¬ 
cer esto, el analista necesita definir cuatro variables en la decisión que va a examinar: condi¬ 
ciones, alternativas de condición, acciones y reglas de acción. 

Una forma de describir decisiones estructuradas es usar el método llamado Español es¬ 
tructurado, en el cual la lógica se expresa en estructuras secuenciales, estructuras de deci¬ 
sión, estructuras de caso o iteraciones. El Español estructurado usa palabras clave aceptadas 
tales como IF, THEN, ELSE, DO, DO WHILE y DO UNTIL para describir la lógica usada 
y se vale de sangrías para indicar la estructura jerárquica del proceso de decisión. 

Las tablas de decisión proporcionan otra forma de examinar, describir y documentar 
decisiones. Cuatro cuadrantes (en el sentido de las manecillas del reloj, empezando desde la 
esquina superior izquierda) se usan para (1) describir las condiciones; (2) identificar las 
posibles alternativas de decisión (como S o N); (3) indicar qué acciones se deben realizar, y 
(4) describir las acciones. Las tablas de decisión son provechosas porque las reglas para de¬ 
sarrollar la propia tabla, así como las reglas para eliminar redundancia, contradicciones y 
situaciones imposibles, son directas y manejables. El uso de tablas de decisión promueve la 
completitud y exactitud al analizar decisiones estructuradas. 

El tercer método para el análisis de decisión es el árbol de decisión, que está integrado 
por nodos (un cuadrado para las acciones y un círculo para las condiciones) y ramas. Los ár¬ 
boles de decisión son apropiados cuando las acciones se deben realizar en una cierta secuen¬ 
cia. No hay necesidad de que el árbol sea simétrico, de modo que en una rama específica sólo 
se encuentran aquellas condiciones y acciones que son críticas para las decisiones. 

Cada uno de los métodos de análisis de decisión tiene sus propias ventajas y se deben 
usar según sea el caso. El Español estructurado es útil cuando se repiten muchas acciones y 
cuando la comunicación con otros es importante. Las tablas de decisión proporcionan un 
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análisis completo de situaciones complejas y limitan la necesidad de cambios atribuíbles a 
situaciones imposibles, redundancias o contradicciones. Los árboles de decisión son impor¬ 
tantes cuando la secuencia apropiada de condiciones y acciones es crítica y cuando cada 
condición no es relevante para cada acción. 

Cada proceso del diagrama de flujo de datos se amplía a un diagrama hijo, diagrama de 
estructura o especificaciones de procesos (como Español estructurado]. Si el proceso es pri¬ 
mitivo, las especificaciones muestran la lógica, la aritmética o el algoritmo para transformar 
la entrada en salida. Estas especificaciones del modelo lógico son parte de las reglas del ne¬ 
gocio (que con frecuencia constituyen una base para crear un lenguaje de procedimientos 
cuando se usan generadores de código). 

Si el proceso se amplía a un diagrama hijo o a un diagrama de estructura, la especifica¬ 
ción de procesos describe el orden y las condiciones bajo las que se ejecutarán los procesos 
del diagrama hijo. Esta lógica de control es parte del modelo físico. 

Las especificaciones de procesos se podrían usar para analizar el diagrama de flujo de 
datos y el diccionario de datos mediante un método llamado balanceo horizontal, el cual 
especifica que todos los elementos de salida del flujo de datos se deben obtener de los ele¬ 
mentos de entrada y de la lógica del proceso. Las áreas sin resolver se pueden plantear como 
preguntas en las entrevistas de seguimiento. 


PALABRAS Y FRASES CLAVE 


acción 

alternativa de condición 
árbol de decisión 
balanceo horizontal 
condición 
contradicción 
decisión estructurada 
Español estructurado 


PREGUNTAS DE REPASO 

1. Mencione tres razones para producir especificaciones de procesos. 

2. Defina lo que significa una decisión estructurada. 

3. ¿Cuáles son los cuatro elementos que el analista de sistemas debe conocer para diseñar 
sistemas para decisiones estructuradas? 

4. ¿Cuáles son los dos elementos esenciales del Español estructurado? 

5. Mencione cinco convenciones que se deben seguir al usar el Español estructurado. 

6. ¿Cuál es la ventaja de usar el Español estructurado para comunicarse con las personas 
en la organización? 

7. ¿Qué cuadrante de la tabla de decisión se usa para las condiciones? ¿Cuál se usa para 
las alternativas de condición? 

8. ¿Cuál es el primer paso a seguir en el desarrollo de una tabla de decisión? 

9. Mencione los cuatro problemas principales que pueden ocurrir en el desarrollo de las 
tablas de decisión. 

10. ¿Cuál es una forma de reducir la complejidad de las tablas de decisión que son difíciles 
de manejar? 

11. ¿Cuál es una de las ventajas principales de las tablas de decisión sobre otros métodos de 
análisis de decisión? 

12. ¿Cuáles son los usos principales de los árboles de decisión en el análisis de sistemas? 

13. Mencione los cuatro pasos principales para construir árboles de decisión. 

14. ¿Cuáles son las tres ventajas que los árboles de decisión tienen sobre las tablas de decisión? 

15. ¿Cuáles son las dos situaciones en que debe usar el Español estructurado? 

16. ¿Cuáles son las dos situaciones en que son más apropiadas las tablas de decisión? 

17. ¿Cuáles son las dos situaciones en que se prefieren los árboles de decisión? 
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especificaciones del proceso 

incompletitud 

miniespecificaciones 

redundancia 

regla de acción 

situación imposible 

tabla de decisión 







18. ¿Cómo pueden ayudar las estructuras de diccionario de datos a determinar el tipo de 
enunciados de Español estructurado para un proceso? 

19. ¿Qué es el balanceo horizontal? ¿Por qué se prefiere para balancear cada proceso? 


PROBLEMAS 

1. Clyde Clerk está revisando las políticas de reembolso de gastos de su empresa con el 
nuevo vendedor, Trav Farr. "Nuestras políticas de reembolso dependen de la situación. 
Vea, primero determinamos si es un viaje local. Si es así, sólo pagamos 18.5 centavos 
por kilómetro. Si el viaje fue de un día, pagamos el kilometraje y después verificamos la 
hora de salida y de regreso. Para pedir el reembolso del desayuno, debe salir a las 7:00 
AM, para el almuerzo a las 11:00 AM y para la cena a las 5:00 PM Para recibir el reem¬ 
bolso del desayuno, debe volver después de las 10:00 AM., del almuerzo después de las 
2:00 PM y de la cena después de las 7:00 PM En un viaje que dura más de un día, au¬ 
torizamos hotel, taxi y boleto de avión, así como también descuentos para la comida. 
Los mismos plazos se aplican para los gastos de la comida." Escriba el Español estructu¬ 
rado para la descripción las políticas de reembolso de Clyde. 

2. Dibuje un árbol de decisión que describa la política de reembolso del problema 1. 

3. Dibuje una tabla de decisión para la política de reembolso del problema 1. 

4. Una empresa de suministros de computadora llamada True Disk ha establecido cuentas 
con innumerables negocios en Dosville. True Disk manda las facturas mensualmente y 
otorga descuentos si los pagos se hacen dentro de los primeros 10 días. La política de 
descuento es la siguiente: si la cantidad del pedido de suministros de computadora es 
mayor que $1,000, resta 4 por ciento del pedido; si la cantidad está entre $500 y 
$1,000, hace un descuento de 2 por ciento; si la cantidad es menor que $500, no aplica 
ningún descuento. Todos los pedidos que se hacen a través de la Web reciben automáti¬ 
camente un descuento extra de 5 por ciento. Cualquier pedido especial (por ejemplo, 
mobiliario de computadora) está exento de todos los descuentos. 

Desarrolle una tabla de decisión para las decisiones de descuento de True Disk, pa¬ 
ra las cuales las alternativas de condición están limitadas a S o N. 

5. Desarrolle una tabla de decisión de entradas extendidas para la política de descuento 
de la compañía True Disk descrita en el problema 4. 

6. Desarrolle un árbol de decisión para la política de descuento de la compañía True Disk 
del problema 4. 

7. Escriba el Español estructurado para resolver la situación de la compañía True Disk del 
problema 4. 

8. Premium Airlines recientemente ha ofrecido resolver una demanda colectiva, que se 
originó por una supuesta fijación de precios de boletos. El arreglo propuesto es el si¬ 
guiente: 


Inicialmente, Premium Airlines pondrá a disposición un fondo principal de $25 
millones en cupones para el arreglo. Si el número de demandas válidas presentadas 
es de 1.25 millones o menos, el valor de cada demanda será el resultado obtenido 
de la división de $25 millones entre el número total de demandas válidas presen¬ 
tadas. Por ejemplo, si hay 500,000 demandas válidas, cada persona que presente 
una demanda válida recibirá un cupón con un valor de $50. 

La denominación de cada cupón distribuido no excederá $50. Por lo tanto, si 
hay menos de 500,000 demandas válidas, el valor de cada demanda se dividirá 
entre dos cupones o más. Por ejemplo, si hay 250,000 demandas válidas, cada per¬ 
sona que presente una demanda válida recibirá dos cupones, teniendo cada uno 
un valor nominal de $50, para un valor total de cupón de $100. 

Si el número de demandas válidas presentadas está entre 1.25 y 1.5 millones, 
Premium Airlines pondrá a disposición un fondo adicional de cupones, con un 
valor potencial de $5 millones. El fondo adicional se extenderá hasta donde sea 
necesario para proporcionar un cupón de $20 para cada demanda válida. 
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Condiciones 
y acciones 


Reglas 

12 3 4 5 6 7 8 9 10 11 12 13 14 15 16 


grande para descuentos 7 : V' Vi'A; Vi CvV-V; . : v— V i V 

Cliente por mayoreo ' 3 S N TI S S H N 3 S-: : N M. S S R N. 

Venta libre de impuestos ■■ S K; S 1L-S : N S --N S N S # S L S N 


Enviar artículos y XXXXXXXX 

preparar factura 
Establecer reabastecimiento 
Deducir descuento X X 

Sumar impuesto de ventas XXX XXX 


XXXXXXXX 



lab tic e Jecistóipaa un 
aimacéri. 


Si hay más de 1.5 millones de demandas válidas, la cantidad total del fondo 
principal y del fondo adicional, $30 millones, se dividirá uniformemente para 
producir un cupón para cada demanda válida. El valor de cada cupón será de $30 
millones divididos entre el número total de demandas válidas. 

Dibuje un árbol de decisión para el arreglo de Premium Airlines. 

9. Escriba el Español estructurado para el arreglo de Premium Airlines del problema 8. 

10. "Bueno, es un poco difícil de describir", dice Sharon, consejero del Less Is More Nutri- 
tion Center. "Realmente nunca he tenido que explicarle a nadie la manera en que co¬ 
bramos a los clientes, pero lo hacemos de la siguiente manera". 

"Cuando los clientes entran en Less Is More, verificamos si han usado nuestro 
servicio anteriormente. Desafortunadamente para ellos, supongo, tenemos muchos 
clientes habituales que regresan una y otra vez. A los clientes habituales se les hace un 
descuento de $100 en la primera visita si vuelven antes que transcurra un año luego del 
final de su programa." 

"Todos los miembros nuevos pagan una cuota inicial de $200 para una evaluación 
física. El cliente podría traer un cupón en este momento y le descontamos $50 de la 
cuota inicial. La mitad de nuestros clientes usa nuestros cupones y con ellos dan con 
nosotros. Sin embargo, sólo emitimos a nuestros clientes habituales sus $100; [asimis¬ 
mo, no pueden usar un cupón! A los clientes que van a uno de nuestros centros en otra 
ciudad se les hace un descuento de $75 en su cuota inicial, pero el cupón no es válido. 
A los clientes que pagan en efectivo se les hace un descuento de 10 por ciento en los 
$200, pero no pueden usar un cupón." 

Cree una tabla de decisión con las condiciones S y N para el sistema de pago del 
cliente en Less Is More Nutrition Center. 

11. Reduzca la tabla de decisión de la figura 9.EX1 al número mínimo de reglas. 


PROYECTOSDEGRUPO 

1. Cada miembro del grupo (o cada subgrupo) debe elegir ser un "experto" y se debe pre¬ 
parar para explicar cómo y cuándo usar una de las siguientes técnicas de decisión es¬ 
tructurada; Español estructurado, tablas de decisión o árboles de decisión. Cada miem¬ 
bro del grupo o subgrupo debe preparar un caso para explicar la utilidad de su técnica 
de análisis de decisión asignada para estudiar los tipos de decisiones estructuradas que 
tomó Maverick Transport en el despacho de camiones particulares a diferentes desti¬ 
nos. Cada grupo debe hacer una presentación de su técnica preferida. 
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2. Después de oír cada presentación, el grupo debe llegar a un acuerdo general de qué téc¬ 
nica es más apropiada para analizar las decisiones de despacho de Maverick Transport y 
por qué esa técnica es mejor en este caso. 


BIBLIOGRAFÍA SELECCIONADA 

Adam, E. E., Jr. y R. J. Ebert, Production and Operations Management, 3a. ed., Englewood 
Cliffs, NJ: Prentice Hall, 1986. 

Anderson, D. R., D. J. Sweeney yT. A. Williams, An Introduction to Management Science, 

8a. ed., Nueva York: West, 1997. 

Awad, E. M., Systems Analysis and Design, 2a. ed., Homewood, IL: Richard D. Irwin, 1985. 
Evans, J. R., Applied Production and Operations Management, 4a. ed., St. Paul, MN: West, 
1993. 

Gane, C. y T. Sarson, Structured Systems Analysis and Design Tools and Techniques, 
Englewood Cliffs, NJ: Prentice Hall, 1979. 



EL PROCESO DE ANALISIS 




ALLEN SCHMIDT, JULIE E. KENDALL Y KENNETH E. KENDALL 



TABLAS DE DECISIÓN 


Después de realizar muchas entrevistas de seguimiento con Dot Matricks, Anna le dice a 
Chip, "he determinado la lógica necesaria para actualizar el almacén de datos PENDING 
COMPUTER ORDERS. Debido a que se podrían pedir muchas computadoras en la misma 
orden de compra, cada vez que se introduce una computadora se localiza el registro corres¬ 
pondiente y se resta uno al número de computadoras pendientes en la orden de compra". 

Anna muestra a Chip la impresión de la pantalla del depósito Process (descrita en al fi¬ 
gura E9.1}. "El nombre del proceso correspondiente, UPDATE PENDING COMPUTER 
ORDER (proceso 2.5], vincula la especificación de proceso con el diagrama de flujo de da¬ 
tos", explica ella. Las entradas y salidas se listan y deben coincidir con el flujo de datos de 
entrada o salida del proceso. "El registro VALID COMPUTER TRANSACTION es el flujo 
de entrada, y el flujo de salida es el PENDING ORDER actualizado." 
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Pantalla Process Reposilory, UPDATE PENDING COMPUTER ORDER. 
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"Eso será útil", dice Chip, "aun cuando tomará tiempo aclararlo todo". 

Anna señala: "El área Process Description contiene la lógica, en inglés estructurado". 

Cuando la lógica está completa, Anna introduce algunos comentarios adicionales sobre 
la naturaleza del proceso, aclarando que es un proceso por lotes, y también agrega informa¬ 
ción sobre los tiempos del proceso. 

Se podría crear una tabla de decisión para la lógica de control o la lógica de proceso. 
Antes de que se teclee la tabla de decisión, es recomendable crearla en papel y optimizarla. 
De esta forma sólo se introducirán las condiciones y acciones esenciales. 

'Yo también he estado ocupado", asegura Chip a Anna. "He hablado con CherWare en 
varias ocasiones desde que la entrevistaste. Finalmente he obtenido algo de la lógica para 
calcular el costo de una actualización de software. 

"Cher indicó tres condiciones diferentes que afectan el costo. La licencia del sitio 
proporciona copias ilimitadas y se usa para el software popular instalado en muchas 
computadoras. Muchos editores hacen un descuento educativo y normalmente se hace un 
descuento por la cantidad", continúa Chip. 

"Primero determiné los valores para las condiciones y el número de combinaciones", di¬ 
ce Chip, quien estableció las tres condiciones y sus valores como sigue: 


Condición 


Valores 


Número de valores 


SITE LICENSE Y/N 2 

EDUCATIONAL DISCOUNT Y/N 2 

DISCOUNT FOR QUANTITY Y/N 2 

"El número total de combinaciones se obtiene multiplicando el número de valores de 
cada condición, 2x2x2 = 8. El siguiente paso es decidir qué condiciones deberán ser las 
primeras." Chip continúa: "concluyo que una licencia del sitio no tendría un descuento por 
cantidad o un descuento educativo adicional, debido a que el costo real de la licencia del si¬ 
tio ya refleja este tipo de descuento. Por lo tanto, la primera condición debe ser SITE LI- 
CENSE. Cada una de las otras dos condiciones no tendría ninguna ventaja particular sobre 
la otra, de modo que el orden no importa. 

"Debido a que el número total de condiciones es ocho y la condición SITE LICENSE 
tiene dos valores posibles, el factor repetitivo sería 8/2, es decir 4." Chip continúa y señala 
que la primera fila de la tabla de decisión sería: 


Condición 


1 2 3 4 5 6 7 8 


SITE LICENSE 


YYYYNNNN 


"La siguiente condición es EDUCATIONAL DISCOUNT que también tiene dos valores. 
Al dividir estos dos valores entre el factor anterior de cuatro se obtiene 4/2 = 2 para el si¬ 
guiente factor que se repite." Chip indica que ahora la tabla de decisión se amplía a: 


Condición 


1 2 3 


SITE LICENSE 

EDUCATIONAL DISCOUNT 


YYYYNNNN 

YYNNYYNN 


jlÉlifpI 


Chip continúa: "La última condición, DISCOUNT FOR QUANTITY, también tiene dos 
valores y al dividir estos dos valores entre el factor de dos anterior que se repite se obtiene 
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2/2 = 1, el cual siempre debe ser el factor repetitivo para la última fila de las condiciones". 
Chip señala que la entrada completa de las condiciones es: 


Condición 


1 

2 

3 4 

5 

6 

7 

8 

SITE LICENSE 

Y 

Y 

Y 

Y 

N 

N 

N 

N 

EDUCATIONAL DISCOUNT 

Y 

Y 

N 

N 

Y 

Y 

N 

N 

DISCOUNT FOR QUANTITY 

Y 

N 

Y 

N 

Y 

N 

Y 

N 

Chip señala que cuando se incluyen las 

acciones 

, la tabla de decisión completa es: 


Condición 




1 2 

3 4 

5 

6 7 

8 

SITE LICENSE 




Y Y 

Y Y 

N 

N N 

N 

EDUCATIONAL DISCOUNT 




Y Y 

N N 

Y 

Y N 

N 

DISCOUNT FOR QUANTITY 




Y N 

Y N 

Y 

N Y 

N 


Acciones 


COST = SITE LICENSE COST 
COST = EDUCATIONAL COSTO x COPIES 
COST = DISCOUNT COSTO x COPIES 
COST = UPGRADE COST x COPIES 
COST = (EDUC COST - DESC) x COPIES 


X X X X 


X 

X 

X 


X 


'Ya reduje algunas de las acciones redundantes, específicamente aquellas que ocurren cuan¬ 
do se obtiene una licencia del sitio", prosigue Chip. "Debido a que las acciones son las mis¬ 
mas para los valores Y de la licencia del sitio, los descuentos educativo y por cantidad no tie¬ 
nen sentido para la condición y no es necesario tomarlos en cuenta. Las reglas 1 a 4 se 
podrían consolidar en una sola." Chip concluye haciendo notar que la tabla de decisión final 
y optimizada es: 




Condición 

12 

3 

4 

5 

SITE LICENSE 

Y N 

N 

N 

N 

EDUCATIONAL DISCOUNT 

— Y 

Y 

N 

N 

DISCOUNT FOR QUANTITY 

— Y 

N 

Y 

N 


Acciones 


COST = SITE LICENSE COST 
COST = EDUCATIONAL COSTO x COPIES 
COST = DISCOUNT COSTO x COPIES 
COST = UPGRADE COST x COPIES 
COST = (EDUC COST - DESC) x COPIES 


X 



X 


X 


La tabla de decisión final, mostrada en la figura E9.2, contiene la tabla de decisión op¬ 
timizada. Hay tres condiciones: que estén disponibles una licencia del sitio, un descuento 
educativo o un descuento por la cantidad. Las condiciones se encuentran en el cuadrante 
superior izquierdo. Las acciones están directamente abajo de éstas. Las alternativas de con¬ 
dición están en el cuadrante superior derecho y las entradas de acción en el cuadrante infe¬ 
rior derecho. Las acciones muestran cómo se determina el costo de actualización para cada 
condición, indicado por una X en las columnas de las reglas. 
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Co ndiciones y acciones 

Site license 
Educational discount 
Discount forquantify 


Upgrade cost = Site license cost 
Upgrade cost = Educational cost * Nurnber of copies 
Upgrade cost = Discount cost* Number of copies 
Upgrade cost = Cost per copy * Number of copies 
Upgrade cost =(Educational cost - Discount) 
‘Number of copies 


N N N 

Y Y N 

Y N Y 
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Tabla de decisión, UPGRADE COST. 





EJERCICIOS 

E-l. Use Visible Analyst para ver la entrada del depósito Process para UPDATE PEND- 
ING COMPUTER ORDER. 

E-2. Modifique e imprima la entrada del proceso ACCUMULATIVE HARDWARE SUB- 
TOTALS. En Process Descriptíon, agregue: "Acumula los subtotales de hardware. Es¬ 
tos incluyen el número de máquinas de cada marca de hardware". 

E-3. Modifique e imprima la entrada del proceso CONFIRM COMPUTER DELETION. 
Agregue lo siguiente en Process Descriptíon: 

Use el COMPUTER RECORD para formatear la pantalla Deletion Confirmation 
(consulte la pantalla Delete Computer Prototype]. 

Pida al usuario que haga clic en el botón OK para confirmar la eliminación; o de lo 
contrario, que haga clic en el botón Cancel para cancelar la eliminación. 

Si el operador hace clic en el botón OK para eliminar el registro, elimina el registro y 
despliega un mensaje "Record Deleted"; de lo contrario, despliega un mensaje "Dele¬ 
tion Canceled". 

E-4. Cree las especificaciones de proceso para el proceso 6.6, VALIDATE COMPUTER 
CHANGES. En Process Descriptíon debe introducir el texto: 

Valide los cambios al COMPUTER MASTER. Incluya una nota para usar los criterios 
de edición establecidos para cada elemento. Proporcione los siguientes criterios de 
edición adicionales: 

La ROOM LOCATION debe ser válida para un campus en particular. 

El MONITOR no debe ser de menor calidad que la taijeta de gráficos. Un ejemplo de 
este error sería una tarjeta de gráficos XGA (la resolución más alta] en un monitor 
SVGA (de menor resolución]. 

No debe haber una segunda unidad de disco duro sin el primero. 

La LAST PREVENTIVE MAINTENANCE DATE no debe ser mayor que la fecha 
actual. 


Los ejercicios precedidos por un icono Web indican material de valor agregado disponible en el sitio 
Web de este libro. Los estudiantes pueden descargar una base de datos de Microsoft Access que pueden 
utilizar para completar los ejercicios. 











La DATE PURCHASED no debe ser mayor que la LAST PREVENTIVE MAINTE- 
NANCE DATE o mayor que la fecha actual. 

El MODEL debe apegarse al tipo soportado en BRAND ÑAME. 

No se pueden realizar cambios a un registro inactivo. 

E-5. Cree las especificaciones del proceso para el proceso 1.4, CREATE SOFTWARE 
LOG FILE. Use los ejemplos de diagramas de flujo de datos para determinar las en¬ 
tradas y salidas. Los detalles del proceso son los siguientes: 

Estructure el SOFTWARE LOG RECORD con la siguiente información: 

Los elementos NEW SOFTWARE RECORD confirmados. 

Los siguientes elementos del sistema: SYSTEM DATE, SYSTEM TIME, USER ID, 
NETWORK ID. 

Cuando se haya estructurado el registro, escriba en el SOFTWARE LOG FILE. 

E-6. Produzca las especificaciones de proceso para el proceso 9.7.2, FIND MATCHING 
HARDWARE RECORD. Este proceso es parte de un programa que produce un in¬ 
forme donde se muestran todas las computadoras en las que se encuentra cada paquete 
de software. Use Visible Analyst para ver el diagrama de flujo de datos 9.7. Use espa¬ 
ñol estructurado para describir la siguiente lógica: 

Para cada SOFTWARE RECORD, repita un ciclo mientras haya un número de inven¬ 
tario de hardware coincidente. Dentro del ciclo, realice las siguientes tareas: 

Lea el archivo COMPUTER MASTER de manera aleatoria. 

Si se localiza un registro, estructure la información MATCHING COMPUTER 
RECORD. 

Si no se localiza registro alguno, estructure una línea de error NO MATCHING. 
Además, si el COMPUTER RECORD localizado está inactivo, indicando que ha si¬ 
do eliminado del servicio, estructure una línea de error INACTIVE MATCHING 
COMPUTER. 

E-7. Use papel o cualquier procesador de texto que incluya una característica para hacer 
tablas para crear la tabla de decisión CALCÚLATE SOFTWARE UPGRADE COST, 
mostrada en la figura E9.2. 

E-8. Cree la tabla de decisión FIND SOFTWARE LOCATION, que representa la lógica 
para un programa de consulta para desplegar todas las ubicaciones de un SOFTWA¬ 
RE TITLE y una VERSION determinados. Las condiciones se han creado y optimiza¬ 
do, y han dado como resultado cinco reglas, ilustradas en la figura E9.3. Introduzca las 
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Tabla de decisión, FIND SOFTWARE LOCATION. 
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acciones necesarias y coloque una X en la columna relacionada con las condiciones. Si 
está usando un procesador de texto, imprima la tabla de decisión final. Las condicio¬ 
nes y acciones están representadas por la siguiente lógica: 

Se localiza el archivo SOFTWARE MASTER para elTITLE especificado. Si no se en¬ 
cuentra el registro correspondiente, se despliega un mensaje de error. Debido a que 
podría haber varias versiones, se revisa el VERSIÓN NUMBER del registro en busca 
de una coincidencia con la versión introducida. Si no se encuentra la versión solicitada, 
se leen registros adicionales usando el índice alterno. Si no se encuentra el número de 
versión después de leer todos los registros, se despliega un mensaje de error VER¬ 
SIÓN NOT AVAILABLE. 

Una vez que se localiza el software correcto, se obtiene un registro COMPUTER 
MASTER coincidente. Sí no se encuentra el COMPUTER MASTER, se despliega el 
mensaje de error MACHINE NOT FOUND. Cuando una máquina coincide, se busca 
el código CAMPUS LOCATION en la CAMPUS TABLE. Si no se encuentra el códi¬ 
go, se despliega el mensaje CAMPUS CODE NOT FOUND. 

Si no se presenta error alguno, se despliega la información solicitada. 

E-9. Cree una tabla de decisión para una actualización por lotes del archivo COMPUTER 
MASTER. Hay tres tipos de actualizaciones: ADD, Delete y Change. 

Debe leerse el registro COMPUTER MASTER. Si la transacción es un Add y no se 
encuentra el archivo maestro, estructure y escriba el nuevo registro COMPUTER 
MASTER. Imprima una línea de transacción válida en un UPDATE REPORT. Para 
una transacción Change o Delete, imprima un mensaje CHANGE ERROR LINE o uno 
DELETE ERROR LINE si no se encuentra el registro COMPUTER MASTER. 

Si se encuentra el registro COMPUTER MASTER, verifique el código activo. Si el re¬ 
gistro está inactivo y la transacción es un Add, estructure y vuelva a escribir el nuevo 
registro COMPUTER MASTER. Imprima una línea de transacción válida en un UP¬ 
DATE REPORT. Para una transacción Change o Delete, imprima un mensaje CHAN¬ 
GE ERROR LINE o uno DELETE ERROR LINE. 

Si el registro COMPUTER MASTER está activo y la transacción es un Add, imprima 
un mensaje ADD ERROR LINE. Para una transacción Change, estructure los cambios 
y vuelva a escribir el registro COMPUTER MASTER. Imprima un mensaje VALID 
TRANSACTION LINE. Para una transacción Delete, cambie el ACTIVE CODE a 
inactivo y vuelva a escribir el registro COMPUTER MASTER. Imprima el mensaje 
VALID TRANSACTION LINE. 
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OBJETIVOS DE APRENDIZAJE 


Una vez que haya dominado el material de este capítulo, podra: 

1. Inventariar y valorar el hardware y el software actuales y propuestos. 

2. Evaluar el sofUvare tomando en cuenta Ips pros y contras entre crear software personalizado, 
comprar software comercial y subcontratado a un: proveedor de servicios de aplicaciones. 

3. Ayudar a los tomadores de decisiones a elegir los,sistemas dé apoyo a la loma de decisiones, 
incluyendo los sistemas de recomendación y las redes neurales. 

4. Pronosticar los costos y beneficios tangibles e intangibles, y realizar un análisis de costos 
y beneficios a través de diversos métodos.. 

5. Escribir y presentar profesionalmente una propuesta de sistemas eficaz, que contenga cifras 

y gráficos. ' .■■ 


1.11 propuesta ele sistemas condensa todo lo que el analista de sistemas ha aprendido acerca 
de una empresa y b> que ésta necesita para mejorar su desempeño. Si desea.satisfacer ade ; 
cuadamónte los requerimiento:»- de información, el analista de sistemas debe usar métodos 
sistemáticos para - la : adquisición de. hardware y software., la ¡deníilicación y pronóstico de 
costos y beneficios futuros y la realización de un análisis de costos \-benoiicios. 'Todos estos 
métodos se usan para preparar el material de la propuesta de sistemas 
i* Las necesidades! de información de los: usuarios determinan l:¡ selección del hardware 
de cómputo, los medios de: almacenamiento de datos y. cualquier software comercial 
(COTS). Iil sistema de hardware \ software que con el tiempo se propone es la respuesta 
del analista a las necesidades de información de los usuarios; f.ste capítulo, proporciona los 
métodos qué se necesitan para proyectar sistemáticamente Lis necesidades futuras y ponde¬ 
rar a continuación las alternativas actuales de hardware y software.También cubre la elabo¬ 
ración de pronósticos, lincamientos! para la adquisición de hardware y soltwaro y¡c-1 análisis 
do'testos y beneficios. ' f’ ;!v.v ! : ; ,. ,’.,!. 


CÓMO DETERMINAR LAS NECESIDADES DE HARDWARE V SOFTWARE 


F.n esta sección aboruamqfv el proceso relacionado con el cálculo de la-, harpas de trabajo 
actuales y í'uUiras de un negocio, y e! proceso relativo a la evaluación do la capacidad del 
hardware y el software de cómputo para manejar adecuadamente las carcas de trabajo, La 
¡ñuur, 1 . 10.1 muestra' lospasos que si A ue H analista de sistemás para determinar las necesida¬ 
des de: hardware y soltware. I'rímero se debe inventariar todo el hardware de cómputo .ac- 
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tual para averiguar lo que está disponible y es utilizable. A continuación se deben calcular 
las cargas de trabajo actuales y futuras del sistema. Después se realiza una evaluación del 
hardware y el software disponibles. 

El analista de sistemas necesita trabajar con los usuarios para determinar qué hardware 
se necesitará. Las determinaciones del hardware sólo se pueden realizar de manera conjunta 
con la determinación de los requerimientos de información. El conocimiento de la estruc¬ 
tura organizacional (como se explicó en el capítulo 2] también puede ser útil para tomar 
decisiones relativas al hardware. Las opciones de hardware sólo se pueden considerar cuando 
los analistas de sistemas, los usuarios y los directivos saben bien cuál es el tipo de tareas que 
se deben realizar. 


CÓMO INVENTARIAR EL HARDWARE DE CÓMPUTO 

Empiece por inventariar el hardware de cómputo que ya existe en la organización. Como 
podrá observar, algunas de las opciones de hardware involucran la ampliación o el reciclaje 
del hardware actual, de modo que es importante saber con qué se cuenta. 

Si no está disponible un inventario actualizado del hardware de cómputo, el analista de 
sistemas tiene que preparar uno rápidamente y trabajar en él. Usted necesita saber lo si¬ 
guiente: 

1. El tipo de equipo: el número de modelo, el fabricante. 

2. El estado de funcionamiento del equipo: en pedido, en funcionamiento, en almacén, 
con necesidad de reparación. 

3. La edad estimada del equipo. 

4. La vida proyectada del equipo. 

5. La ubicación física del equipo. 

6. El departamento o la persona responsable del equipo. 

7. La situación financiera del equipo: propio, en arrendamiento financiero, alquilado. 

La determinación del hardware actual disponible dará como resultado un proceso de 
toma de decisiones más acertado cuando finalmente se decida qué hacer con el hardware. 
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ya que se eliminará gran parte de las suposiciones sobre lo que en realidad existe. Gracias a 
las entrevistas, cuestionarios e investigación de datos almacenados que realizó previamente, 
ya conoce la cantidad de personas disponible para el procesamiento de datos así como sus 
habilidades y aptitudes. Use esta información para proyectar qué tan bien pueden satisfa¬ 
cerse las necesidades de nuevo hardware del personal. 

CÁLCULO DE LAS CARGAS DE TRABAJO 

El próximo paso en la determinación de las necesidades de hardware es calcular las cargas 
de trabajo. Así, los analistas de sistemas establecen cifras que representan las cargas de tra¬ 
bajo actuales y proyectadas para el sistema con el fin de que cualquier hardware que se ad¬ 
quiera cuente con la capacidad para manejar las cargas de trabajo actuales y futuras. 

Si las estimaciones se realizan adecuadamente, la empresa no debe reemplazar el hard¬ 
ware tan sólo por el crecimiento inesperado en el uso del sistema. (Sin embargo, otros even¬ 
tos, como innovaciones tecnológicas superiores, pueden dictar el reemplazo del hardware si 
la empresa quiere mantener su ventaja competitiva.) 

Aparte de la necesidad, las cargas de trabajo se muestrean en lugar de completarlas 
realmente en varios sistemas de cómputo. Los lincamientos sobre el muestreo proporcio¬ 
nados en el capítulo 5 pueden ser útiles aquí, ya que en el muestreo de las cargas de trabajo 
el analista de sistemas toma una muestra de las tareas necesarias y los recursos de cómpu¬ 
to requeridos para completarlas. 

La figura 10.2 es una comparación de los tiempos requeridos por un sistema de infor¬ 
mación actual y uno propuesto que se supone manejan una carga de trabajo dada. Observe 
que la compañía está usando actualmente un sistema manual para preparar un resumen 
mensual de los envíos a sus almacenes de distribución, y se está sugiriendo un sistema de 
cómputo. La comparación de las cargas de trabajo toma en cuenta el costo por hora de ca- 
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da sistema, cuándo y cómo se realiza cada proceso, cuánto tiempo humano se requiere y 
cuánto tiempo de la computadora se necesita. 


EVALUACIÓN DEL HARDWARE DE CÓMPUTO 

La evaluación del hardware de cómputo es una responsabilidad compartida de los directi¬ 
vos, usuarios y analistas de sistemas. Aunque los fabricantes proporcionarán detalles acerca 
de los productos que ofrezcan, los analistas necesitan supervisar personalmente el proceso de 
evaluación porque ellos se preocuparán por los mejores intereses del negocio. Además, tal 
vez los analistas de sistemas tengan que enseñar a los usuarios y a los directivos las ventajas y 
desventajas generales del hardware para que puedan evaluarlo de manera eficaz. 

Con base en el inventario actual del equipo de cómputo y en las estimaciones adecua¬ 
das de las cargas de trabajo actuales y futuras, el siguiente paso en el proceso es considerar 
los tipos de equipo disponibles que parezcan satisfacer las necesidades proyectadas. La in¬ 
formación que los fabricantes ofrezcan acerca de los posibles sistemas y las configuraciones 
de éstos será más apropiada en esta fase y debe revisarse de manera conjunta con los direc¬ 
tivos y los usuarios. 

Además, las cargas de trabajo se pueden simular y ejecutar en diferentes sistemas, in¬ 
cluyendo los que ya se usan en la organización. Este proceso se llama benchmarking (evalua¬ 
ción comparativa). 

Entre los criterios que los analistas de sistemas y los usuarios deben usar para evaluar el 
desempeño de los diferentes sistemas de hardware están los siguientes: 

1. El tiempo requerido para las transacciones promedio (incluyendo cuánto tiempo toma 
la entrada de datos y cuánto obtener la salida). 

2. La capacidad de volumen total del sistema (cuánto se puede procesar al mismo tiempo 
antes de que ocurra un problema). 

3. El tiempo que la unidad central de procesamiento se mantiene inactiva. 

4. El tamaño de la memoria proporcionada. 

Algunos criterios se presentarán en demostraciones formales; algunos no se pueden 
simular y es necesario obtenerlos de las especificaciones de los fabricantes. Durante las de¬ 
mostraciones es importante estar seguro de cuáles son las funciones requeridas y cuáles las 
deseadas antes de analizar detalladamente las afirmaciones de los fabricantes. 

Una vez que se conocen los requerimientos funcionales y que se comprenden los pro¬ 
ductos actuales disponibles y se comparan con los que ya existen en la organización, los ana¬ 
listas de sistemas deciden en conjunto con los usuarios y los directivos si es necesario obtener 
nuevo hardware. Se puede considerar que las opciones van desde utilizar únicamente equi¬ 
po disponible en el negocio hasta adquirir equipo totalmente nuevo. Entre estos dos puntos 
hay opciones intermedias como la de hacer modificaciones menores, o mayores, al sistema 
de cómputo actual. 

Tamaño y uso de la computadora El rápido avance de la tecnología obliga a los analistas de 
sistemas a investigar qué tipos de computadoras están disponibles en el momento específi¬ 
co en que se escribe la propuesta de sistemas. El tamaño de las computadoras va desde las 
pequeñas computadoras Palm que caben en una mano hasta las supercomputadoras que 
podrían ocupar toda una sala. Cada una tiene atributos diferentes que se deben considerar 
al decidir cómo implementar un sistema de cómputo. 


ADQUISICIÓN DEL EQUIPO DE CÓMPUTO 


Las tres opciones principales para la adquisición de hardware de cómputo son la compra, el 
arrendamiento financiero o el alquiler. Como se muestra en la figura 10.3, hay ventajas y 
desventajas que se deben analizar para cada una de las decisiones. Algunos de los factores 
que se deben tomar en cuenta al momento de determinar cuál opción es mejor para una 
instalación en particular incluyen los costos iniciales versus los costos a largo plazo, si la em- 
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presa se puede dar el lujo de invertir capital en el equipo de cómputo y si desea tener el 
control total y la responsabilidad sobre el equipo de cómputo. 

La compra implica que la empresa poseerá el equipo. Uno de los principales factores 
que determinan la compra es la vida proyectada del sistema. Si el sistema se usará por más 
de cuatro a cinco años (con todos los demás factores constantes], normalmente se toma la de¬ 
cisión de comprar. Observe que en el ejemplo de la figura 10.4 el costo de compra después 
de tres años es más bajo que el del arrendamiento financiero o el alquiler. Conforme los sis¬ 
temas se hacen más pequeños y aumenta la popularidad de los sistemas distribuidos, la ma¬ 
yoría de las empresas se decide por comprar equipo. 

Otra posibilidad distinta a la compra es el arrendamiento financiero del hardware. 
Arrendar el equipo al fabricante o a una compañía de arrendamiento de terceros es más 
práctico cuando la vida proyectada del sistema es menor a cuatro años. Además, si es inmi¬ 
nente un cambio significativo en la tecnología, el arrendamiento financiero constituye una 
mejor opción. Este esquema también permite a la empresa poner su dinero en otra parte, 
donde puede ser más rentable para la compañía en lugar de invertirlo en bienes de capital. 
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Sin embargo, el arrendamiento a largo plazo no es una forma económica de adquirir equipo 
de cómputo. 

La tercera opción para la adquisición de computadoras es el alquiler del hardware de 
cómputo. Una de las ventajas principales del alquiler es que no se invierte el capital de la com¬ 
pañía y por lo tanto no se requiere ningún fmanciamiento. También, alquilar el hardware de 
cómputo facilita cambiar el hardware del sistema. Por último, el mantenimiento y el seguro 
se incluyen por lo general en el contrato de alquiler. Sin embargo, debido a los altos costos 
que implica y al hecho de que la compañía no será dueña del equipo alquilado, el alquiler 
sólo se debe considerar como un movimiento a corto plazo para satisfacer necesidades no 
recurrentes o limitadas de cómputo o los tiempos volátiles de la tecnología. 

Evaluación del soporte técnico del fabricante para el hardware de cómputo Diversas 
áreas importantes se deben evaluar al analizar los servicios de soporte técnico que los fabri¬ 
cantes ponen a disposición de las empresas. La mayoría de los fabricantes ofrece una prueba 
de hardware en la entrega y una garantía de 90 días que cubre cualquier defecto de fabrica¬ 
ción, pero usted debe averiguar qué más ofrece el fabricante. Los fabricantes de calidad 
comparable frecuentemente se distinguen de otros por la gama de servicios de soporte téc¬ 
nico que ofrecen. 

En la figura 10.5 se proporciona una lista de los principales criterios que se deben veri¬ 
ficar al evaluar el soporte técnico del vendedor. La mayoría de los servicios adicionales de 
soporte técnico del fabricante que se mencionan allí se negocian por separado de los contra¬ 
tos de arrendamiento o compra del hardware. 

Los servicios de soporte técnico incluyen mantenimiento rutinario y preventivo del 
hardware, el tiempo de respuesta especificado en caso de falla del equipo (menos de seis 
horas, el siguiente día laborable, etc.], préstamo de equipo en caso de que el hardware se de¬ 
ba reemplazar permanentemente o que se requiera una reparación externa, y capacitación 
para los usuarios. Lea cuidadosamente los documentos de los servicios de soporte técnico 
que acompañan a la compra o arrendamiento del equipo y recuerde pedir asesoría al perso¬ 
nal de su departamento legal antes de firmar los contratos para equipo o servicios. 

Por desgracia, evaluar el hardware de cómputo no es tan sencillo como simplemente 
comparar los costos y seleccionar la opción más accesible. Algunas otras eventualidades que 
normalmente plantean los usuarios y los directivos incluyen: (1) la posibilidad de agregar 
componentes al sistema si surge la necesidad de hacerlo; (2) la posibilidad de interactuar con 
el equipo de otros fabricantes si el sistema necesita crecer; (3) la posibilidad de comprar 
más memoria que la proyectada, con la expectativa de que en el futuro el negocio "crecerá", 
y (4) la estabilidad corporativa del fabricante. 

De la competencia entre los fabricantes ha surgido la idea de producir hardware com¬ 
patible con el hardware de los competidores importante para la supervivencia de los fabri- 
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cantes. Sin embargo, antes de convencerse de que comprar compatibles más baratos es la 
forma de proveer a su sistema de capacidad adicional, investigue a fondo hasta asegurarse 
de que el fabricante original es una entidad corporativa estable. 


EVALUACIÓN DEL SOFTWARE 

Al evaluar el software para los proyectos de sistemas de información, los analistas y las or¬ 
ganizaciones se enfrentan cada vez más con la disyuntiva de hacer, comprar o subcontratar, 
particularmente al contemplar las actualizaciones a los sistemas actuales o los heredados. 

Ya vio las decisiones que los analistas toman cuando tienen que elegir entre alquilar, 
comprar o arrendar el hardware. Algunas de las decisiones relacionadas con la compra de 
software comercial, "alquiler" de software de un proveedor de servicios de aplicaciones 
(ASP] o la creación de software personalizado para el proyecto son análogas a las del proce¬ 
so de toma de decisiones relativas al hardware. 

Observe que independientemente de si desarrolla el software o compra un producto 
comercial para un proyecto particular, es indispensable que primero realice un análisis de 
requerimientos de información de los usuarios y los sistemas (como se explicó en los capí¬ 
tulos anteriores). En su papel de analista, parte de su preparación consiste en aprender a 
juzgar de manera razonable si es más conveniente desarrollar software o comprar software 
comercial para los sistemas nuevos y los existentes. Las secciones siguientes discuten cuán¬ 
do crear su propio software, cuándo comprar paquetes comerciales y cuándo recurrir a un 
ASP. La figura 10.6 resume las ventajas y desventajas de cada una de estas opciones. 

Cuándo crear software personalizado Hay varias situaciones que requieren la creación de 
software original o componentes de software. El caso más común es cuando no se encuen- 
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tra o no existe software comercial para la aplicación deseada. O bien, tal vez el software 
exista pero es incosteable o es difícil comprarlo o adquirir una licencia. 

El software original se debe crear cuando la organización busque una ventaja competiti¬ 
va mediante el uso de sistemas de información reforzado con un despliegue estratégico. Por 
lo regular éste es el caso cuando la organización crea aplicaciones de comercio electrónico u 
otras aplicaciones innovadoras en áreas donde no existen. También es posible que la organi¬ 
zación sea "pionera" en el uso de una tecnología particular o en la industria en que se desen¬ 
vuelve. Las organizaciones que tienen requerimientos sumamente especializados o las que 
operan en industrias basadas en nichos de mercado, también se pueden beneficiar del 
software original. 

Las ventajas de crear su propio software incluyen la capacidad de responder a las nece¬ 
sidades especializadas del negocio, ganar una ventaja competitiva al crear software innova¬ 
dor, disponer de personal interno para dar mantenimiento al software y el orgullo de poseer 
algo que uno mismo ha creado. 

Entre las desventajas de desarrollar su propio software están la posibilidad de un costo 
inicial significativamente más alto comparado con la compra de software comercial o con la 
contratación de un ASP, la necesidad de contratar o trabajar con un equipo de desarrollo y 
el hecho de que usted es responsable del mantenimiento continuo porque usted creó el 
software. 


Cuándo comprar software comercial El software comercial incluye productos como Mi¬ 
crosoft Office, que incluye a Word para el procesamiento de texto, Excel para las hojas de 
cálculo, Access para desarrollar bases de datos y otras aplicaciones. Hay otros tipos de soft¬ 
ware comercial para sistemas empresariales más que para uso personal o de oficina. Algunos 
autores incluyen paquetes ERP populares (pero costosos] como PeopleSoft, Oracle y SAP 
en sus ejemplos de software comercial. Estos paquetes difieren radicalmente en la cantidad 
requerida de personalización, soporte y mantenimiento en comparación con Microsoft 
Office. El software comercial también se puede referir a componentes u objetos de software 
(también llamados componentes básicos] que se pueden comprar para proporcionar una 
funcionalidad particularmente necesaria en un sistema. 

Considere el uso de software comercial cuando pueda integrar fácilmente las aplicacio¬ 
nes o paquetes en los sistemas actuales o en los planeados, y cuando esté seguro de que no 
tendrá una necesidad inmediata o continua de cambiarlos o personalizarlos. Sus pronósticos 
deben demostrar que es poco probable que la organización para la cual está diseñando el 
sistema experimente cambios importantes después de la compra propuesta de software co¬ 
mercial, tales como un aumento significativo de clientes o grandes expansiones físicas. 

Hay algunas ventajas al comprar software comercial que usted debe tener presente al 
considerar las alternativas. Una ventaja es que estos productos se han refinado a través del 
uso y distribución comercial, de modo que con frecuencia ofrecen funcionalidades adicio¬ 
nales. Otra ventaja es que por lo general el software empaquetado se prueba ampliamente y 
por ello es muy confiable. 

A menudo el software comercial ofrece funcionalidades adicionales, debido a que es 
probable que un producto comercial sea miembro de una familia de productos, tenga carac¬ 
terísticas adicionales y actualizaciones que lo hacen más atractivo. Adicionalmente, los ana¬ 
listas a menudo encuentran que el costo inicial del software comercial es más bajo que el 
del software que se desarrolla de manera interna o el de recurrir a un ASP. 

Otra ventaja de comprar paquetes comerciales es que los usan otras compañías, así que 
los analistas no experimentan con sus clientes aplicaciones de software únicas en su tipo. 
Por último, el software comercial tiene la ventaja de que en la compra del software empa¬ 
quetado se incluye soporte y capacitación. 

Un ejemplo del uso de software comercial es el de una compañía de teatro del sector 
no lucrativo, en el cual las organizaciones (particularmente las que tienen que ver con las 
artes teatrales] tienden a rezagarse de sus contrapartes que sí persiguen fines de lucro en 
la adopción de tecnologías de información y comunicación (ICTs]. Como era de esperar, la 
compañía de teatro tardó en entrar a Internet. Cuando quisieron crear aplicaciones de co- 
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mercio electrónico, tuvieron que contratar diseñadores externos para que se encargaran de 
esta tarea. Considerando el gasto que esto representaba, y la falta de especialistas internos, 
muchas organizaciones no lucrativas simplemente no transfirieron a la Web la parte de ne¬ 
gocios de sus organizaciones, y esperaron en cambio paquetes comerciales, como software 
de taquilla basado en PCs, o ASPs como las agencias de venta de boletos en línea con auto¬ 
matización ya establecida, para poner estos servicios a disposición de sus clientes habituales. 
El desarrollo interno de software estaba fuera del alcance para la mayoría de estos grupos, 
los cuales por lo general cuentan con pocos o ningún especialista de IT, presupuestos muy 
limitados y poca experiencia con la tecnología. 

Hay un inconveniente al utilizar software comercial. Debido a que no está destinado a 
personalizarse completamente, la compañía de teatro perdió su capacidad de cambiar el 
software para incluir características importantes en su base de datos de donadores. El soft¬ 
ware comercial también podría incluir errores que expondrían a la organización a proble¬ 
mas de responsabilidad legal. 

Hay otras desventajas que se deben considerar al comprar software comercial, inclu¬ 
yendo el hecho de que los paquetes se enfocan en la programación y no en el negocio. Adi¬ 
cionalmente, los usuarios deben vivir con todas las características del software, sean o no 
apropiadas. Una desventaja que se origina de esto es la limitada capacidad de personaliza¬ 
ción de la mayor parte del software empaquetado. Otras desventajas de comprar software 
comercial incluyen la necesidad de investigar la estabilidad financiera del fabricante del 
software, y el menor sentido de pertenencia y compromiso inevitables cuando el software se 
considera un producto en lugar de un proceso. 

Cuándo subcontratar los servicios de desarrollo de software con un proveedor de servicios 
de aplicaciones Las organizaciones podrían obtener algunos beneficios de tomar un enfo¬ 
que totalmente diferente para adquirir software. Esta tercera opción es subcontratar algunas 
de las necesidades de software de la organización a un proveedor de servicios de aplicacio¬ 
nes (ASP) que se especialice en aplicaciones de IT. 

Hay beneficios específicos de subcontratar las aplicaciones con un ASP. Por ejemplo, 
quizá a las organizaciones que desean conservar su enfoque estratégico y concentrarse en 
lo que son mejores les convenga subcontratar la producción de las aplicaciones de sistemas 
de información. Adicionalmente, la subcontratación de las necesidades de software implica 
que la organización que hace la subcontratación evita la necesidad de contratar, capacitar y 
retener muchos empleados de IT Esto puede producir ahorros significativos. Cuando una 
organización usa un ASP, hay poco o ningún gasto del valioso tiempo del empleado en ta¬ 
reas innecesarias de IT [éstas las maneja profesionalmente el ASP}. 

Contratar un proveedor de servicios de aplicaciones no se debe considerar una fórmu¬ 
la mágica para solucionar los requerimientos de software. Hay desventajas en el uso de un 
ASP que se deben considerar seriamente. Una desventaja es la pérdida general del control 
sobre los datos corporativos, sistemas de información, empleados de IT e incluso en el proce¬ 
samiento y en la calendarización de proyectos. Algunas compañías creen que la información 
es el corazón de su negocio, e incluso la idea de ceder el control de ésta es inquietante. Otra 
desventaja tiene que ver con la viabilidad financiera de cualquier ASP que se escoja. La se¬ 
guridad de los datos y registros de la organización también podría representar una preocu¬ 
pación, junto con la confidencialidad de los datos y la privacidad del cliente. Finalmente, al 
escoger un ASP, la corporación pierde la posibilidad de obtener una ventaja estratégica que 
podría haber ganado con el despliegue de sus propias aplicaciones innovadoras. 

Evaluación del soporte técnico del fabricante de software y de los ASPs Si compra un pa¬ 
quete comercial o contrata los servicios de un ASP, estará tratando con vendedores que en 
el fondo podrían estar preocupándose por sus propios intereses. Usted debe mostrar dispo¬ 
sición para evaluar el software con los usuarios y no dejarse influir excesivamente por los ar¬ 
gumentos de ventas de los fabricantes. Como se muestra en la figura 10.7, específicamente 
hay seis categorías principales para clasificar el software: efectividad del desempeño, efi¬ 
ciencia del desempeño, facilidad de uso, flexibilidad, calidad de documentación y soporte 
técnico del fabricante. 
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dSSUBAESZiS v i ■ H 8 S¡S!Í Requerimientos de software Características específicas de software 

Lineamientos para evaluar ------— , r : —- ■ ■— —— —■—— : — - 

el software. Efectividad de! desempeño Capaz de realizar todas las tareas requeridas 

Capaz de realizar todas las tareas deseadas 
Pantallas de despliegue bien diseñadas 
Capacidad adecuada 

Eficiencia del desempeño Tiempo de respuesta rápido 

Entrada eficiente 
Salida eficiente 

Almacenamiento de datos eficiente 
Respaldo eficiente 


Facilidad de uso Interfaz de usuario satisfactoria ; 

Menús de ayuda disponibles: 

Archivos "Léame" para notificar los cambios de último 
momento 

; Interfaz flexible.- CV.S 

Retroalimentación adecuada 
Buena recuperación de errores: 

Flexibilidad Opciones de entrada 

Opciones de salida 
Utilizable con otro software 


Calidad de documentación 


Soporte del fabricante 


Buena organización 

Manual en línea adecuado 

Sito Web con preguntas frecuentes i 

Soporte técnico permanente en línea 
Boletín/correo electrónico 

Sitio Web con actualizaciones de productos que se 
pueden descargar 


Evalúe el software empaquetado con base en una demostración con datos de prueba de 
la empresa que considera su compra y un análisis de la documentación incluida. Las des¬ 
cripciones de los fabricantes por sí solas no serán suficientes. Normalmente los fabricantes 
certifican que el software funciona cuando sale de las instalaciones del distribuidor, pero no 
garantizan que siempre estará libre de errores o que no fallará cuando los usuarios realicen 
acciones incorrectas. Obviamente, no garantizarán su software empaquetado si se usó con 
hardware defectuoso. 

HERRAMIENTAS DE APOYO A LA TOMA DE DECISIONES 

Aunque algún software comercial podría resolver ciertos problemas de procesamiento de 
información, el analista de sistemas también necesita contar con capacidad para evaluar, re¬ 
comendar o apoyar el uso de herramientas de toma de decisiones y sistemas de apoyo a la 
toma de decisiones en los niveles medio y estratégico de la organización. 

AHP y otro software de múltiples criterios Hay una amplia disponibilidad de paquetes de 
software comercial que se basan en el procesamiento jerárquico analítico (AHP) y otros ti¬ 
pos de software de toma de decisiones multicriterios. En la figura 10.8 se mencionan algunos 
de estos paquetes. 

El software de apoyo a la toma de decisiones requiere que los objetivos del tomador de 
decisiones estén bien definidos, que se conozcan sus prioridades y que se incluyan explícita¬ 
mente los criterios de decisión. El analista también podría ayudar al tomador de decisiones 
recopilando y proporcionando información sobre cada una de las alternativas. Esta informa¬ 
ción normalmente se llama atributo. 

Para ilustrar esto, considere la decisión de comprar el automóvil más conveniente para 
uso personal (el objetivo). Primero procuraríamos identificar los modelos de automóviles 
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"Realmente se tiene que haceruna elección. Quiero decir, ningún pa¬ 
quete parece tener todo lo que necesitamos. Sin embargo, algunos de 1 
ellos se acercan a lo que buscamos", dice Román, ejecutivo de publici¬ 
dad efe- Empire Magazine con quien usted ha estado trabajando en un 
proyecto de sistemas. Recientemente, ustedes dos decidieron que tal vez 
el software comercial satisfaga; las; necesidades del departamento de > 
, publicidad y detenga v su deterioro general, ; : ; 

"La demostración del último tipo que vimos, usted sabe, el que tra¬ 
bajó para Data Collseum, realmente tenía una buena presentación. Y me; 
gusta su folleto. Impresión a todo color, en cartulina. Clásico", afirma 


"¿Y la gente deVesta Systems? Realmenteestán prendidos. Y su pa- : 
quete era fácil de usar con un mínimo de requisitos. Además, ellos dije¬ 
ron que nos darían capacitación a los 12 que somos, en nuestras Insta¬ 
laciones, sin nirigúri cargo. Pero mira su publicidad. Tornan las cosas tan 
pronto salen de la impresora." 7 ; = ; r : 

Román se balancea en su silla mientras continúa su revisión muy 
particular del software y los fabricantes del software. "Ese paquete de 


Mars, Inc., realmente se vendió por sí solo. Es decir, tenía un calendario 
¡ncorporadorY me gusta la manera en que los menús para los desplie¬ 
gues de pantalla 1 se pueden elegir mediante números romanos. Eran fá¬ 
ciles de seguir. Y no será difícil convencer al fabricante de que baje el 
precio A Creo'que ellos ya están en una guerra de precios." : 

; "¿Quiere usted saber quién es mi favorito?", pregunta Román mali- 
: ciosamente; "Es el publicado por Júpiter, Unlimlted. Es decir, tiene todo, 
¿no cree? Cuesta un poco más, pero hace lo que nosotros necesitamos, y 
la documentación;-es;bastante extensa. Ellos no dan ninguna capacita- 
ciórtj por supuesto. Creen que eso está fuera de su competencia." 

: Usted ya estápensando cómo contestar las preguntas de Román en 
su fecha tope del 15 de marzo, necesita evaluar el software así como los 
fabricantes, sistemáticamente, y presentar una decisión. Evalúe a cada 
fabricante y paquete-con base en lo que ha dicho Román hasta ahora 
(suponga que puede confiaren Sus opiniones). ¿Cuáles son los prejuicios 
evidéntesdé Román al evaluar al software y los fabricantes? ¿Qué Infor¬ 
mación adicional necesita usted sobre cada compañía y su software an¬ 
tes de decidirse por alguno? 


de entre los cuales elegiríamos (nuestras alternativas}. Después determinaríamos qué valora¬ 
mos de un automóvil, incluyendo el precio, cuánto combustible gasta por kilómetro, seguri¬ 
dad, valor de reventa, comodidad y otras características (nuestros criterios), después valora¬ 
ríamos estos criterios por su importancia, dando quizás al precio un valor (o prioridad] de 
.20, un valor de .10 al combustible que gasta por kilómetro, y así sucesivamente hasta que 
asignemos un valor total de 1.00 o 100 por ciento. 

Finalmente, determinaríamos una calificación para cada uno de los automóviles que 
consideráramos, con base en cada uno de los criterios. La calificación podría expresarse de 
muchas formas, como en una escala de 1 a 10, con el 10 como el mejor. Por ejemplo, un 
Honda podría recibir una calificación de 9 por la seguridad. 

Algunas herramientas de decisión usan AHP, la cual pide al tomador de decisiones que 
compare el modelo de un automóvil con otro y después con otro, hasta que se hagan todas 
las comparaciones en pares. Por lo tanto, AHP no requiere que se cuantifiquen los valores de 
atributos. Otros modelos de decisión requieren cuantificar los atributos y después usan 
otros métodos tal como programación por metas o restricciones conjuntas para apoyar al 
tomador de decisiones en una elección. 

SISTEMAS EXPERTOS, REDES NEURALES Y OTRAS HERRAMIENTAS DE DECISIÓN 

Otros modelos de decisión disponibles para gerentes incluyen sistemas expertos y las redes 
neurales. Los sistemas expertos son sistemas de razonamiento basados en reglas que se de- 


Producto 


Compañía 


Sitio Web 


Crystal Bn 2000 Decsoneemg www.decisioneering-.com 
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Info Harvest 


www.infoharvest.com 


Expert Choice 


ExpertChoice 
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o con técnicas de criterios 
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sarrollan por un experto en el campo. Recopilar las experiencias se llama adquisición de 
conocimiento y es la parte más difícil de la especificación del conjunto de reglas para el sis¬ 
tema general. A partir de ahora, puede asumir que las herramientas de software están am¬ 
pliamente disponibles en todas las categorías del precio. Un ejemplo es Exsys CORVID 
(www.exsys.com). 

Las redes neurales se desarrollan para resolver varios problemas de un tipo y para per¬ 
mitir que el software obtenga retro alimentación de las decisiones, observando lo que estaba 
involucrado en las decisiones exitosas. Este proceso se conoce como entrenar la red neural. 

Con frecuencia estos dos modelos caen en el dominio de la inteligencia artificial. ¿Qué 
hacen en los sistemas de apoyo a la toma de decisiones? Normalmente, necesitan de un to¬ 
mador de decisiones humano para identificar el problema, adquirir el conocimiento y hacer 
análisis de sensibilidad. Raramente se dejan solas estas decisiones en la computadora. La 
complejidad de la resolución de los problemas permite que estas técnicas sean parte del 
mundo del sistema de apoyo a la decisión. 

Sistemas de recomendación Estos son sistemas de software y de base de datos que per¬ 
miten a los tomadores de decisiones reducir el número de alternativas mediante el orde¬ 
namiento, el conteo o algún otro método. Una guía de restaurante, como Zagat's, es un 
ejemplo de un sistema de recomendación. Encuesta a los comensales y da los resultados en 
línea y en un libro; la información para cenar en algunas ciudades importantes está disponi¬ 
ble para transmitir a los dispositivos portátiles inalámbricos. Un término ampliamente usa¬ 
do para el proceso es el filtrado cooperativo. 

Todo el tiempo se desarrollan sistemas de recomendación más sofisticados. Hay sistemas 
que permiten a los usuarios evaluar las alternativas ya sea mediante un sistema numérico 
(como 1 a 7) o un sistema alfanumérico (A-F, como las calificaciones]. Los usuarios pueden 
conseguir el filtrado cooperativo de libros, automóviles, películas actuales, etcétera. 

Un sistema de recomendación no depende de los valores numéricos. Este sistema cuen¬ 
ta el número de ocurrencias, tal como cuántas personas guardan un cierto sitio Web o 
cuántos usuarios mencionaron a un autor. Un ejemplo de un sistema de recomendación es 
Net Perceptions (www.netperceptions.com), el cual es el responsable del filtrado coopera¬ 
tivo en Amazon.com. 

Obtención de información externa desde Web A veces, los tomadores de decisiones nece¬ 
sitan filtrar su propia información en lugar de recurrir a sistemas de recomendación. Podemos 
clasificar esta información como noticias sobre la economía, competencia de industria, etc. 
Sin embargo, los datos en Web son dinámicos y es difícil predecir cómo obtendrán los eje¬ 
cutivos su información durante los siguientes años. En la figura 10.9 hay un muestreo de 
varios tipos de servicios que un tomador de decisiones puede usar para obtener información 
externa sobre cosas como la economía, clientes o tendencias. 
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Fuentes selectas para la 
información externa disponibles 
en Web. 


Tipo de servicio 


Producto 


Sitio Web 


Tecnologías de actualización 
automática 


Páginas de Inicio 
personalizadas 


Periódico en línea 


Agentes inteligentes 


BackWeb 

Marimba Castanet ' 

My Yahoo! 

Personal Start Page 
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London Times 
New York Times,? 
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EXPERIENCIA CON HYPERCASE® 


"Aquí se han tomado muchas decisiones. Usted se sorprendería de los tipos de cosas que in¬ 
cluso los ayudantes administrativos como yo tenemos que decidir. Y al momento, no después 
de largas horas de análisis. No se trata de cuestiones triviales. Al parecer las computado¬ 
ras podrían ayudarnos a decidir la mayoría de las cosas si simplemente las planeáramos. Todas 
estas decisiones ¡ 7 hoc que tomamos podrían requerir un poco de apoyo. Creo que Snowden 
se inclinaría por ello. Yo puedo ver los beneficios." 

PREGUNTAS DE HYPERCASE 

1. ¿En qué parte de MRE sería adecuado un sistema de apoyo a la toma de decisiones? 

2. ¿Quién (qué empleados de MRE) se beneficiaría más de un DSS? Indique por qué. 

3. Identifique tres decisiones semiestructuradas multicriterios que requieren juicio huma¬ 
no y de computadoras, que se estén tomando en la Unidad de Capacitación y Sistemas 
de Administración. Escoja una para apoyar con un DSS. Explique su elección. 




Las tecnologías de actualización automática [el primer grupo) tienen gran potencial. 
Los ejecutivos pueden configurar uno de estos productos para recibir noticias desde Inter¬ 
net directamente en sus computadoras personales, o en algunos casos en las computadoras 
Palm inalámbricas, teléfonos celulares o radiolocalizadores que usan el protocolo de aplica¬ 
ción inalámbrica. Una versión de un producto de actualización automática también puede 
servir como un protector de pantalla, con un mensaje de noticias que avanza por la pantalla 
muy parecido a un mensaje bursátil. Las páginas de inicio personalizadas se pueden establecer 
para buscar información específica. Los periódicos en línea son buenos para buscar, debido 
a que el usuario tiene el control de una búsqueda amplia. Finalmente, los agentes inteligen¬ 
tes conocen su personalidad, aprenden su comportamiento y rastrean los temas que ellos 
piensan que usted necesita mantener actualizados. 


COMO IDENTIFICAR Y PRONOSTICAR LOS COSTOS Y BENEFICIOS 

Siempre se deben considerar en conjunto los costos y beneficios del sistema de cómputo pro¬ 
puesto, debido a que con frecuencia están vinculados y dependen uno del otro. Aunque el 
analista de sistemas está intentando proponer un sistema que cumple los diversos requeri¬ 
mientos de información, las decisiones de continuar con el sistema propuesto se basarán en 
el análisis de costo-beneficio, no en los requerimientos de información. En gran medida, los 
beneficios se miden por los costos, como se aprecia en la siguiente sección. 


COMO PRONOSTICAR LOS COSTOS Y BENEFICIOS 

Se necesita que los analistas de sistemas pronostiquen ciertas variables importantes antes de 
enviar la propuesta al cliente. Hasta cierto punto, un analista de sistemas se apoyará en un 
análisis de "qué pasa si", tal como, "¿Qué pasa si los costos de mano de obra suben sólo 5 por 
ciento por año durante los próximos tres años, en lugar de 10 por ciento?" Sin embargo, el 
analista de sistemas debe entender que él o ella no se pueden apoyar únicamente en un aná¬ 
lisis del tipo "qué pasa si" si quieren que la propuesta sea creíble, significativa y valiosa. 

El analista de sistemas tiene disponibles muchos modelos de predicción. La condición 
principal para escoger un modelo es la disponibilidad de los antecedentes. Si no están dispo¬ 
nibles, el analista debe volver a uno de los métodos de discernimiento: las estimaciones de 
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la fuerza de ventas, estudios para estimar la demanda del cliente, estudios Delphi (un pro¬ 
nóstico del acuerdo general desarrollado independientemente por un grupo de expertos a 
través de una serie de iteraciones], crear guiones o dibujar las analogías históricas. 

Si los antecedentes están disponibles, la siguiente diferencia entre las clases de técnicas 
involucra si el pronóstico es condicional o incondicional. El condicional implica que hay 
una asociación entre las variables en el modelo o que dicha relación causal existe. Los mé¬ 
todos comunes en este grupo incluyen correlación, regresión, indicadores principales, eco- 
nometría y modelos de entrada/salida. 

El pronóstico incondicional significa que no se necesita del analista para encontrar o 
identificar cualquier relación causal. Por consiguiente, los analistas de sistemas encuen¬ 
tran que estos métodos son alternativas económicas y de fácil implementación. En este 
grupo se incluyen el juicio gráfico, medias móviles y análisis de datos de serie de tiempo. 
Debido a que estos métodos son simples, fiables y rentables, el resto de la sección se enfoca 
en ellos. 

Estimación de las tendencias Las tendencias se pueden estimar de diferentes formas. 
Las técnicas más ampliamente usadas son (1) el juicio gráfico, (2) el método de mínimos 
cuadrados y [3] la media móvil. A continuación se presenta una breve explicación de estas 
técnicas. 

Juicio gráfico. La forma más simple de identificar una tendencia y las tendencias de 
pronóstico futuras es por juicio gráfico, el cual se realiza simplemente al observar un gráfi¬ 
co y al estimar una prolongación de una línea o curva a pulso. En la figura 10.10 se ilustra 
un ejemplo de juicio gráfico. 

Las desventajas de este método son obvias al mirar los gráficos en la figura. La prolon¬ 
gación de la línea o curva podría depender demasiado del juicio individual y no represen¬ 
taría la situación actual. Sin embargo, el método de juicio gráfico es útil debido a que ha 
aumentado la habilidad de desempeñar el análisis de sensibilidad ("qué pasa si") con la in¬ 
troducción de hojas de cálculo electrónicas. 

Método de mínimos cuadrados. Cuando una línea de tendencia se construye, los 
puntos de datos reales quedarán a cada lado de esa línea. El objetivo en la estimación de una 
tendencia usando el método de mínimos cuadrados es encontrar la línea más apropiada al 
minimizar la suma de las desviaciones de una línea. Una vez encontrada la línea más apro¬ 
piada, se puede granear y la línea se puede prolongar para pronosticar lo que pasará. 

La línea más apropiada, o línea de mínimos cuadrados, se desarrolla a partir de los 
puntos de datos (Xj, Y,), (X 2 , Y 2 ). .., (X N , Y N ), donde las coordenadas de X representan 
los periodos y las coordenadas de Y representan la variable que el analista de sistemas inten¬ 
ta pronosticar. La ecuación para la línea de mínimos cuadrados se expresa de la forma 

Y=m. *X+b 

donde la variable m representa la pendiente de la línea y b representa interceptar a Y, el 
punto en que la línea intercepta el eje de Y. 





Recomendamos un método más eficaz, en términos de los cálculos requeridos, para en¬ 
contrar la ecuación de mínimos cuadrados, calculando el centro de gravedad de los datos to¬ 
mando x = X-Xyy = Y - Y y después calculando la línea de mínimos cuadrados como 


por último sustituir X - X por % y Y - Y por y. 

En Excel, puede calcular la tendencia basada en mínimos cuadrados directamente al 
usar la función Tendencia. 

Promedios móviles. El método de promedios móviles es útil porque algunos modelos 
estacionales, cíclicos o aleatorios se podrían suavizar, dejando el modelo de la tendencia. La 
principal función de los promedios móviles es calcular el promedio aritmético de datos de 
grupos o periodos, usando la ecuación 

Y,, + Y,_+ • • « + 

Ñ 

donde ÍV representa el número de periodos. Después calcule el próximo promedio aritmé¬ 
tico descartando los datos del periodo antiguo y agregando los datos del periodo actual: 

Y2 + Y3 + • • • + Y m ,| 

N 

En la figura 10.11 se muestra un tipo de promedio móvil. Aquí, se promedian los datos 
de cinco años y se indica la cifra resultante. Incluso, observe que los años 1993 a 1997 se 
promedian para pronosticar 1998, después se promedian los años 1994 a 1998 para pronos¬ 
ticar la cantidad para 1999, etc. Cuando los resultados se grafican, es muy notorio que los 
datos ampliamente variables se suavizan. 

El método de promedio móvil es útil por su habilidad suavizadora, pero al mismo tiem¬ 
po tiene muchas desventajas. Los valores extremos afectan en mayor medida a las medias 
móviles que a los métodos de juicio gráfico y de mínimos cuadrados. 

Muchos paquetes de elaboración de pronósticos importantes están disponibles para 
PCs y computadoras centrales. El analista debe conocer bien la elaboración de pronósticos, 
conforme proporciona la información valiosa de justificación el proyecto entero. 


IDENTIFICACIÓN DE BENEFICIOS Y COSTOS 

Los beneficios y costos se pueden representar como tangibles o intangibles. Cuando se con¬ 
sideran los sistemas se deben tener en cuenta los beneficios y costos tangibles e intangibles. 
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Los beneficios intangibles incluyen mejorar el proceso de toma de decisiones, incre¬ 
mentar la exactitud, ser más competitivo en el servicio al cliente, mantener una buena ima¬ 
gen del negocio e incrementar la satisfacción del trabajo para los empleados eliminando las 
tareas tediosas. Como puede juzgar de la lista dada, los beneficios intangibles son sumamente 
importantes y pueden tener consecuencias transcendentales para el negocio conforme rela¬ 
ciona a las personas fuera y dentro de la organización. 

Aunque los beneficios intangibles de un sistema de información son factores impor¬ 
tantes que se deben considerar al decidir proceder con un sistema, un sistema construido 
únicamente por sus beneficios intangibles no tendrá éxito. Debe discutir los beneficios 
tangibles e intangibles en su propuesta, debido a que presentar ambos permitirá a toma¬ 
dores de decisiones del negocio tomar una decisión bien documentada acerca del sistema 
propuesto. 

Costos tangibles Los conceptos de costos tangibles e intangibles presentan una semejanza 
conceptual al de los beneficios tangibles e intangibles ya discutidos. Los costos tangibles son 
aquellos que el analista de sistemas y el personal de contabilidad del negocio pueden pro¬ 
yectar con precisión. 

Incluidos en los costos tangibles están el costo de equipo tal como las computadoras y 
terminales, el costo de recursos, el costo del tiempo de analistas de sistemas, el costo del 
tiempo de programadores y sueldos de otros empleados. Por lo regular estos costos están 
bien establecidos o se pueden descubrir muy fácilmente y son los costos que requerirán un 
desembolso en efectivo del negocio. 

Costos intangibles Los costos intangibles son difíciles de estimar y podrían ser desconoci¬ 
dos. Éstos incluyen perder una ventaja competitiva, perder la reputación por no ser el pri¬ 
mero con una innovación o un líder en un campo, deterioro de la imagen de la compañía 
debido al incremento en la insatisfacción del cliente y toma de decisiones ineficaz debido a 
la información inoportuna o inaccesible. Como puede imaginar, es casi imposible proyectar 
con precisión una cantidad en dólares para los costos intangibles. Para ayudar a tomadores 
de decisiones que quieren evaluar el sistema propuesto y todas sus implicaciones, debe in¬ 
cluir los costos intangibles aunque no sean cuantificables. 


"<OTM¡^RÁCÍ0Ñ^ET^l3ref0SVBEÑEFÍCÍ0S 

Se conocen muchas técnicas para comparar los costos y beneficios del sistema propuesto. 
Dichas técnicas incluyen análisis del punto de equilibrio, análisis del tiempo de recuperación 
de la inversión, análisis de flujo de efectivo y análisis de valor presente. Todas estas técnicas 
proporcionan formas directas de producir información para los tomadores de decisiones so¬ 
bre el valor del sistema propuesto. 

ANÁLISIS DEL PUNTO DE EQUILIBRIO 

Al comparar los costos por separado, el analista de sistemas puede usar el análisis del punto 
de equilibrio para determinar la capacidad de equilibrio del sistema de información pro¬ 
puesto. El punto en el que los costos totales del sistema actual y el sistema propuesto se 
intersecan representa el punto de equilibrio, el punto donde es rentable para el negocio la 
adquisición del nuevo sistema de información. 

Los costos totales incluyen los costos que se repiten durante el funcionamiento del sis¬ 
tema más los costos de desarrollo que sólo ocurren una vez [los costos anteriores a la ins¬ 
talación de un nuevo sistema), es decir, los costos tangibles que se explicaron en la sección 
anterior. La figura 10.12 es un ejemplo de análisis del punto de equilibrio en un almacén 
pequeño que mantiene el inventario usando un sistema manual. Conforme aumenta el vo¬ 
lumen, los costos del sistema manual suben a una proporción creciente. Un nuevo sistema 
de cómputo costaría una suma considerable por adelantado, pero los costos increméntales 
para un volumen alto serían bastante pequeños. El gráfico muestra que el precio del sistema 
de cómputo sería efectivo si el negocio vende aproximadamente 600 unidades por semana. 
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Análisis del punto de equilibrio 
para el sistema de inventario 
propuesto. 



Costo del sistema 
propuesto 


Costo del sistema 
actual 


El análisis del punto de equilibrio es útil cuando un negocio está creciendo y el volu¬ 
men es una variable importante en los costos. Una desventaja del análisis del punto de equi¬ 
librio es que se da por hecho que los beneficios se mantendrán iguales, sin tener en cuenta 
qué sistema está funcionando. De nuestro estudio de beneficios tangibles e intangibles, sa¬ 
bemos que ése no es exactamente el caso. 

El análisis del punto de equilibrio también puede determinar cuánto tiempo tomará re¬ 
cuperar los costos de desarrollo del sistema. La figura 10.13 ilustra un sistema con un perio¬ 
do de recuperación de tres años y medio. 



Análisis del punto de equilibrio 
que muestra un periodo de 
recuperación de tres años 
y medio. 


ANÁLISIS DE FLUJO DE EFECTIVO 

El análisis de flujo de efectivo examina la dirección, tamaño y modelo del flujo de efectivo 
que se asocia con el sistema de información propuesto. Si está proponiendo el reemplazo de 
un sistema de información viejo por uno nuevo y si este último no generará ningún ingreso 
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EXPERIENCIA CON HYPERCASE® 


"A yetes las personas que han estado aquí durante algún tiempo se sorprenden de cuánto 
hemos crecido realmente. Sí, admito que no es fácil llevar'un control de lo que le correspon¬ 
de a cada persona o incluso de las compras dehardwáre y software que ha hecho cada de¬ 
partamento. No obstante, estamos trabajando en’ello. A Snowden le gustaría ver un mayor 
aprovechamiento dé las computadora que se adquieren. Él desea asegurarse de qué sabe¬ 
mos lo que tenemos, dónde está, por qué lo tenemos, quién lo usa y si está impulsando; la 
productividad de MRE, o, como él delicadamente lo plantea, 'ver si es simplemente unju- 
guete caro ! sin el cual podemos arreglárnoslas". 

PREGUNTAS DE HYPERCASÉ 

1. Realice un inventario del equipo de cómputo de la Unidad de Sistemas de Gapacita- 
; ción y Administración, que describa todos los sistemas que haya usted encontrado. SM- 

gerenda: Cree un Formulario de inventario para simplificar su tarea. 

2. Con los lincamientos para evaluar software que vio en el texto, haga una breve evalua- 
ción de GEMS, tin paquete de software usado por los empleados de Sistemas de Admi¬ 
nistración. En un párrafo, critique brevemente este software personalizado y compárelo 
con algún software comercialcomo Microsoft Project. 

3. Mencione los costos y beneficios intangibles de GEMS con base en los informes pro¬ 
porcionados por los empleados de MRE. 

4. Describa brevemente las dos alternativas que Snowden está considerando para el siste¬ 
ma de seguimiento y elaboración de informes de proyectos propuesto. : : 

5. ¿Qué factores organizacionales y políticos debe considerar Snowden al proponer su nue¬ 
vo sistema a MRE? (En un párrafo breve, explique tres conflictos centrales.) 




adicional para el negocio, sólo desembolsos de efectivo están asociados con el proyecto. Si 
ése es el caso, el nuevo sistema no se puede justificar con base en flujos de efectivo y se de¬ 
be examinar estrechamente buscando otros beneficios tangibles si es que se planea conti¬ 
nuar trabajando en el proyecto. 

En la figura 10.14 se muestra un análisis de flujo de efectivo para una compañía peque¬ 
ña que está proporcionando un servicio de mensajería a otras compañías pequeñas en la 
ciudad. Las proyecciones de ingresos son que sólo se generarán $5,000 en el primer trimes¬ 
tre, pero después del segundo trimestre, el ingreso incrementará a una proporción firme. 
Los costos serán grandes en los primeros dos trimestres y después se estabilizarán. El análisis 
de flujo de efectivo se usa para determinar cuándo tiene una ganancia una compañía (en es¬ 
te caso, está en el tercer trimestre, con un flujo de efectivo de $7,590} y cuándo estará "en 
números negros", es decir, cuando el ingreso ha recuperado la inversión inicial (en el primer 
trimestre del segundo año, cuando el flujo de efectivo acumulado cambie de una cantidad 
negativa [roja] a una positiva [negra] $10,720). 

El sistema propuesto debe haber aumentado los ingresos junto con los desembolsos de 
efectivo. Después el tamaño del flujo de efectivo se debe analizar junto con los modelos del 
flujo de efectivo asociados con la compra del nuevo sistema. Debe preguntar cuándo ocu¬ 
rrirán los desembolsos de efectivo e ingresos, no sólo para la compra inicial, sino también en 
la vida del sistema de información. 


ANALISIS DE VALOR PRESENTE 

El análisis de valor presente permite al analista de sistemas presentar a tomadores de deci¬ 
siones del negocio el valor de tiempo de la inversión en el sistema de información así como 
también el flujo de efectivo (como se discutió en la sección anterior). El valor presante es 


PREPARACION DE LA PROPUESTA DE SISTEMAS 




Tom 

-xiiá-lisu ?3 ..i >3'pe.éípctiyo para 

ei sistema compuiarizado de 


diréccionamiento de correo. 


trimestre 1 

Trimestre 2 

Año 1 

Trimestre 3 

Trimestre 4 

Año 2 

Trimestre 1 

i¡ .lngnlsp.il ;i , r ,:g,„ 

Costos 

Desarrollo 
de software 

lili 

10,000 

MllüQOpIt'll | ¡ | ¡ | f 

5,000 

-R;:$ái,270;7; 

'Vftsy-f.í¡j 

Personal 

Capacitación 

Arrendamiento 

8,000 

3,000 

8,400 

6,000 

8,800 

9,260 

9,700 

de equipo 

4,000 

4,000 

4,000 

4,000 

4,000 

Suministros 

1,000 

2,000 

2,370 

2,990 

3,730 

Mantenimiento 

0 

2,000 

2,200 

2,420 

2,660 

Flujo de efectivo 

26.000 

27.400 

17.370 

18.670 

20,090 

idtJstiJs tíjiáles i 

2||||¡¡ 

7+7,400 

7,590 


: 18,930 

Flujo de efectivo 





acumulado 

21,000 

-28,400 

-20,810 

-8,210 

10,720 


una forma de evaluar todos los desembolsos económicos e ingresos del sistema de informa¬ 
ción sobre su vida económica, y para comparar los costos actuales con los costos futuros y 
los beneficios actuales con los beneficios futuros. 

En la figura 10.15, el sistema tiene un costo total de $272,000 en un periodo de seis 
años y beneficios totales de $280,700. Por lo tanto, podríamos concluir que los beneficios 
pesan más que los costos. Sin embargo, los beneficios sólo empezaron a superar a los costos 
después del cuarto año y los dólares en el sexto año no serán equivalentes a los dólares en el 
primer año. 

Por ejemplo, hoy una inversión de un dólar a 7 por ciento de interés anual, valdría 
$1.07 al final del año y se duplicará en aproximadamente 10 años. Por lo tanto, el valor pre¬ 
sente es el costo o el beneficio medido en dólares actuales y depende del costo de dinero. El 
costo de dinero es el costo de oportunidad de costo o la tasa que se podría obtener si el di¬ 
nero invertido en el sistema propuesto se invirtiera en otro proyecto que fuera relativamen¬ 
te seguro. 

El valor presente de $1.00 a una tasa de descuento de i se calcula determinando el factor 

1 

( 1 + 0 » 

donde n es el número de periodos. Después el factor se multiplica por la cantidad de dine¬ 
ro, la producción del valor presente es como se muestra en la figura 10.16. En este ejem¬ 
plo, el costo de dinero —la tasa de descuento— se supone es .12 (12 por ciento) para el 
horizonte entero de la planeación. Los multiplicadores se calculan para cada periodo: n = 1, 
n = 2,. . n~ 6. Los valores presentes de costos y beneficios después se calculan usando 
estos multiplicadores. Cuando se da este paso, los beneficios totales (medidos en dólares ac¬ 
tuales) son $179,484, y por ello menores que los costos (también medidos en dólares actua¬ 
les). La conclusión a obtener es que el sistema propuesto no vale la pena si se considera el 
valor presente. 

Año 

1 2 3 4 5 6 Total 

C’ostq^JÍ $40.000 -2, ,(X)0 .:.+14,100 46.300 48.600 51.000 ' 272,000.'' 

Beneficios $25,000 31,-200 39,000 48,700 60,800 76,000 280,700 



Sin considerar el valor presente, 
los beneficios parecen valer más 
que los costos. 
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Aunque este ejemplo, el cual usa factores de valor presente, es útil para explicar el con¬ 
cepto, todas las hojas de cálculo electrónicas tienen integrada una función del valor presen¬ 
te. El analista puede calcular directamente el valor presente usando esta característica. 

L1NEAMIENT0S PARA EL ANÁLISIS 

El uso de los métodos discutidos en las subdivisiones precedentes depende de los métodos 
empleados y aceptados en la organización misma. Sin embargo, para los lincamientos gene¬ 
rales se puede decir con seguridad lo siguiente: 



Tomando en cuenta el valor 


presente, la conclusión es que ! 
los costos son mayores que los . 
beneficios." La tasa de descuento, 
7, se sobreentiende cómo .12 en 
el cálculo dé los multiplicadores 
en esta tabla. . • • • • •' 


1. Use el análisis del punto de equilibrio si es necesario justificar el proyecto en lo que se 
refiere al costo, no los beneficios, o si los beneficios no aumentan considerablemente 
con el sistema propuesto. 

2. Use el análisis del tiempo de recuperación de la inversión cuando los beneficios tangi¬ 
bles obtenidos por el nuevo sistema representen un argumento convincente para pro¬ 
mover el sistema propuesto. 

3. Use el análisis de flujo de efectivo cuando el proyecto es relativamente caro, compara¬ 
do con el tamaño de la compañía o cuando el negocio se afectaría significativamente 
por un gasto tan grande [aun cuando sea temporal]. 

4. Use el análisis de valor presente cuando el periodo de recuperación de la inversión es 
largo o cuando el costo de pedir prestado dinero es alto. 

Cualquier método que se escoja, es importante recordar que el análisis de costo-beneficio 
se debe aproximar sistemáticamente, de forma que se pueda explicar y justificar ante la di¬ 
rección, que es quien eventualmente decidirá si autoriza los recursos para el proyecto de 
sistemas. En la siguiente sección analizamos la importancia de comparar muchas alternati¬ 
vas de sistemas. 


CÓMO EXAMINAR US ALTERNATIVAS DE SISTEMAS 

Con el uso del análisis del punto de equilibrio, análisis del tiempo de recuperación de la in¬ 
versión, análisis de flujo de efectivo y el análisis de valor presente, es posible comparar las 
alternativas para el sistema de información. Como se mostró anteriormente, es importante 
usar análisis múltiples para cubrir adecuadamente las limitaciones de cada enfoque. Aunque 
considerará varias alternativas, la propuesta en sí recomendará sólo una. De tal manera, 
que habrá hecho un análisis comparativo sobre qué sistema hace el mejor sentido económi¬ 
co antes de que se escriba la propuesta. Dichos análisis se pueden incluir para proporcionar 
apoyo para el sistema que está recomendando. 

No piense que sólo hay una solución "correcta" del sistema para ayudar a un negocio a 
resolver sus problemas y alcanzar su meta. Diferentes negocios requieren atributos de dife¬ 
rentes sistemas, y los analistas de sistemas difieren sobre la mejor forma de manejar una va¬ 
riedad de problemas del negocio. 

El punto importante es que necesita comparar y contrastar las opiniones en una forma 
tan justa como sea posible con el propósito de ofrecer una opción viable a los tomadores de 
decisiones de la organización. Entre más condensada esté la identificación inicial y acepta- 
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ción del sistema propuesto, habrá mayores probabilidades de su uso continuo y aceptación 
una vez que el sistema está en el lugar. Continúe incluyendo a tomadores de decisiones 
en la planeación, aunque ahora usted debe, de alguna forma, asumir el papel del experto en 
sistemas. 


LA PROPUESTA DE SISTEMAS 

ORGANIZACIÓN DE LA PROPUESTA DE SISTEMAS 

Una vez que ha recopilado el material que se debe incluir en su propuesta de sistemas, 
necesita juntarlo en piezas de una manera lógica y visualmente eficaz. Necesita incluir 10 
secciones funcionales principales, use un estilo de escritura eficaz, use las figuras para com¬ 
plementar su escritura y enfóquese en los detalles visuales de la propuesta escrita. 


Qué incluir en la propuesta de sistemas Diez secciones principales comprenden la pro¬ 
puesta escrita de sistemas. Cada parte tiene una función particular y la propuesta eventual 
se debe colocar en el siguiente orden: 


1. Carta de presentación. 

2. Portada. 

3. Tabla de contenidos. 

4. Resumen ejecutivo [incluyendo las recomendaciones}. 

5. Lincamiento del estudio de sistemas con la documentación apropiada. 

6. Resultados detallados del estudio de sistemas. 

7. Alternativas de sistemas (tres o cuatro soluciones posibles). 

8. Recomendaciones de analistas de sistemas. 

9. Resumen de la propuesta. 

10. Apéndices (documentación diversa, resumen de fases, correspondencia, etcétera). 

La propuesta de sistemas debe llevar una carta de presentación para la dirección y la 
fuerza de tarea de IT. Dicha carta debe mencionar las personas que hicieron el estudio y re¬ 
sumir los objetivos de ese estudio. Mantenga la carta de presentación concisa y amistosa. 

Incluya en la carta de presentación el nombre del proyecto, los nombres de los miem¬ 
bros del equipo del análisis de sistemas y la fecha en que se envió la propuesta. El título de la 
propuesta debe expresar con precisión el contenido de la propuesta, pero también puede 
exhibir alguna imaginación. La tabla de contenidos puede ser útil a los lectores de propues¬ 
tas largas. Si la propuesta es menor a 10 páginas, omita la tabla de contenidos. 

El resumen ejecutivo, en 250 a 375 palabras, proporciona el quién, qué, cuándo, dónde, 
por qué y cómo de la propuesta, tal como sería el primer párrafo en una historia de noticias. 
También debe incluir las recomendaciones de los analistas de sistemas y lo que desearía 
fueran las acciones de la dirección, ya que algunas personas sólo tendrán tiempo para leer el 
resumen. El resumen ejecutivo se debe escribir al final, cuando ya se haya escrito el resto de 
la propuesta. 

El lineamiento del estudio de sistemas proporciona información sobre todos los méto¬ 
dos usados en el estudio y quién o qué se estudió. Cualesquier cuestionarios, entrevistas, 
muestreo de datos del archivo, observación o elaboración de prototipos usados en el estudio 
de sistemas se deben discutir en esta sección. 

La sección de resultados detallados describe lo que el analista de sistemas ha averigua¬ 
do sobre el sistema a través de todos los métodos descritos en la sección anterior. Aquí se 
deben observar las conclusiones sobre los problemas de sistemas que han surgido durante el 
estudio. Esta sección debe plantear los problemas o sugerir las oportunidades que requieren 
las alternativas de solución presentadas en la próxima sección. 

En la sección de alternativas de sistemas de la propuesta, el analista presenta dos o tres 
soluciones alternativas que se dirigen directamente a los problemas antes mencionados. Las 
alternativas que presenta deben incluir una que recomienda mantener el sistema igual. Ca¬ 
da alternativa se debe explorar por separado. Describa los costos y beneficios de cada situa- 
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ción. Debido a que normalmente hay pros y contras involucrados en cualquier solución, 
asegúrese de incluir las ventajas y desventajas de cada una. 

Cada alternativa debe indicar claramente lo que la dirección debe hacer para imple- 
mentarla. La redacción debe ser tan clara como sea posible, tal como, "Comprar compu¬ 
tadoras portátiles para todos los gerentes de nivel medio", "Comprar software empaquetado 
para manejar el inventario" o "Modificar el sistema actual a través de consolidar los esfuer¬ 
zos de la programación internas". 

Después de que el equipo de análisis de sistemas ha pesado las alternativas, tendrá una 
opinión profesional definida sobre qué solución es más utilizable. La sección de las reco¬ 
mendaciones de analistas de sistemas expresa la solución recomendada. Incluye las razones 
que apoyan la recomendación del equipo para que sea fácil entender por qué se hace. La re¬ 
comendación debe fluir lógicamente del análisis de soluciones alternativas presentado en la 
sección anterior. 

El resumen de la propuesta es una declaración breve que refleja el contenido del resu¬ 
men ejecutivo. Proporciona los objetivos del estudio y la solución recomendada. El analista 
una vez más debe destacar la importancia del proyecto y viabilidadjunto con el valor de las 
recomendaciones. Concluya la propuesta en una nota positiva. 

El apéndice es la última parte de la propuesta de sistemas y puede incluir cualquier in¬ 
formación que el analista de sistemas sienta es de interés para individuos específicos, pero 
no es esencial para entender el estudio de sistemas y lo que se está proponiendo. 

Una vez que se escribe la propuesta de sistemas, seleccione cuidadosamente quién debe 
recibir el informe. Entregue personalmente el informe a las personas que ha seleccionado. 
Su visibilidad es importante para la aceptación y el éxito futuro del sistema. 


USO DE CIFRAS PARA UNA COMUNICACIÓN EFICAZ 

Hasta ahora, el énfasis de esta sección ha sido considerar a su público al elaborar la propues¬ 
ta de sistemas. Las tablas y gráficos así como también las palabras son importantes en la cap¬ 
tura y comunicación de los elementos esenciales del sistema propuesto. 

Integrar cifras en su propuesta ayuda a demostrar que es sensible a las diferentes for¬ 
mas en que las personas absorben la información. Las cifras en el informe complementan 
la información escrita y siempre se deben interpretar con palabras; nunca se deben poner 
solas. 

Uso eficaz de las tablas Aunque las tablas técnicamente no son apoyos visuales, propor¬ 
cionan una forma diferente de agrupar y presentar datos procesados que el analista quiere 
comunicar al lector de la propuesta. Las tablas son más parecidas a las figuras que al texto 
escrito, y por consiguiente se discuten aquí. 

Las tablas usan columnas y filas etiquetadas para presentar los datos estadísticos o alfa¬ 
béticos de una forma organizada. Cada tabla se debe numerar de acuerdo con el orden en 
que aparece en la propuesta y se debe titular significativamente. En la figura 10.17 se mues¬ 
tra el diseño y etiquetado adecuado para una tabla. 

Algunos lineamientos para las tablas son los siguientes: 

1. Integre tablas en el cuerpo de la propuesta. No los relegue a los apéndices. 

2. Intente acomodar la tabla de forma vertical en una sola página si es posible. 

3. Numere y titule la tabla en la parte superior de la página. Haga el título descriptivo y 
significativo. 

4. Etiquete cada fila y columna. Si es necesario use una o más líneas para el título. 

5. Use una tabla con marco si el espacio lo permite. Las columnas con líneas guía vertica¬ 
les reforzarán la legibilidad. 

6. Use notas de pie de página si es necesario para explicar detalladamente la información 
contenida en la tabla. 
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üneamientos para crear tablas 
eficaces. 



En las secciones anteriores se presentaron varios métodos para comparar costos y benefi¬ 
cios. En la propuesta de sistemas deben aparecer los resultados presentados de esas compa¬ 
raciones. Si se hace un análisis de punto de equilibrio, se debe incluir una tabla que presente 
los resultados del análisis. El análisis del tiempo de recuperación de la inversión se puede 
mostrar en tablas que sirven como apoyo adicional para los gráficos. En la propuesta de sis¬ 
temas también se podría incluir una breve tabla que compare los sistemas de cómputo u 
opciones. 


Uso eficaz de los gráficos Esta sección trata diferentes tipos de gráficos: gráficos de líneas, 
gráficos de columnas, gráficos de barras y gráficos circulares. Los gráficos de líneas, gráficos 
de columnas y gráficos de barras comparan las variables, mientras que los gráficos circulares 
ilustran la composición de 100 por ciento de una entidad. 

Los lincamientos para incluir gráficos eficaces en una propuesta son como sigue: 

1. Escoja un estilo de gráfico que comunique bien su propósito deseado. 

2. Integre el gráfico en el cuerpo de la propuesta. 

3. Asigne al gráfico un número de figura secuencial y un título significativo. 

4. Etiquete cada eje y cualesquier líneas, columnas, barras o segmentos del círculo en el 
gráfico. 

5. Incluya una clave para indicar las líneas coloreadas de forma diferente, barras sombrea¬ 
das o áreas cuadriculadas. 


En la figura 10.18 se muestra un ejemplo de cómo podría aparecer un gráfico en una pági¬ 
na de la propuesta de sistemas. Nuestra explicación de gráficos empieza con el tipo más 
simple, llamado gráfico de líneas. 
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Gráficos de líneas. Los gráficos de líneas se usan principalmente para mostrar el cam¬ 
bio con el tiempo. Ningún otro tipo de gráfico muestra una tendencia más claramente que 
un gráfico de líneas. Los cambios en una sola variable o en hasta cinco variables se pueden 
ilustrar en un solo gráfico de líneas. 

Sin embargo, a veces un gráfico de líneas se usa para mostrar algo más que tiempo en el 
eje horizontal. Como se muestra en la figura 10.19, esta situación ocurre cuando uno tiene 
que estimar cuándo se cortan dos o más líneas. En este ejemplo, el sistema actual es el me¬ 
nos caro hasta que el Equipo de Annie crezca aproximadamente a 24,000 unidades por año. 
Después los servicios de datos de computadora ofrecen la opción menos cara. Después en- 



PREPARACION DE LA PROPUESTA DE SISTEMAS 


PuCICOtt CT 












Un gráfico de área es un tipo 
de gráfico de líneas que podría 
causar un mayor impacto. 



contramos que Syscom es la opción menos cara si Annie creciera anualmente alrededor de 
28,000 unidades. 

Un método importante de comparación visual, en la misma familia general de los grá¬ 
ficos de líneas, es el gráfico de área. En la figura 10.20 se muestra el crecimiento de la in¬ 
dustria de DVD durante el periodo 1998-2003. En este gráfico de área, los ingresos brutos 
totales consisten en las ventas (el área inferior y más clara] y las rentas (el área superior y 
más oscura]. El gráfico de área es muy útil cuando la diferencia entre dos variables se ex¬ 
tiende en gran medida. 

Los gráficos de líneas son formas excelentes de mostrar a los lectores de la propuesta 
cómo podría cambiar la demanda en el sistema de cómputo en un cierto número de años o có¬ 
mo podría cambiar la demanda para los productos o servicios de un negocio dentro de un 
periodo específico. 

Los gráficos de líneas también son útiles para representar resultados de análisis del 
tiempo de recuperación de la inversión o de análisis de punto de equilibrio a tomadores de 
decisiones. El despliegue gráfico del tiempo de recuperación de la inversión es una forma 
excelente de retratar la viabilidad económica del sistema propuesto, ya que es un gráfico de 
los resultados del punto de equilibrio. 

Gráficos de columnas. Otro tipo familiar de gráfico es el gráfico de columnas. Los 
gráficos de columnas con el tiempo pueden describir una comparación entre dos o más va¬ 
riables, pero se usan con mayor frecuencia para comparar diferentes variables en un perio¬ 
do particular. Aunque no muestran las tendencias tan claramente como el gráfico de líneas 
—ni tampoco uno puede estimar fácilmente el valor de cada columna— a muchas personas 
se les hace más fácil entender los gráficos de columnas que los gráficos de líneas. 


Más de una variable se puede 
desplegar en un gráfico de 
columnas sombreando 
o coloreando las barras de la 


columna. 
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Se puede usar un gráfico de 
columnas al 100 por ciento para 
mostrar parte del porcentaje en 
todo momento.)..: : 


Año 


En la figura 10.21 se muestra un gráfico de columnas con más de una variable. En esta 
situación, las columnas se dibujan de diferentes colores o sombras para distinguir entre las 
variables. Observe que hay espacio entre cada una de las dos clases (HQ y tropas A, B, C, D 
y E) pero no hay espacio entre dos variables, "potencia actual" y "mínimo requerido". 

También hay formas especiales de gráficos de columnas. En la figura 10.22 se muestra 
un gráfico de columnas apilado al 100 por ciento. Este tipo de gráfico se usa para mostrar la 
relación entre dos variables que constituyen 100 por ciento de una entidad. Aquí, las ventas 
de artículos deportivos las constituye el equipo deportivo de competencia y el equipo re¬ 
creativo. El gráfico muestra que el equipo deportivo competitivo ha crecido como un por¬ 
centaje de ventas totales. (Sin embargo, no muestra las ventas reales que de hecho pueden 
estar bajando aunque el porcentaje esté creciendo.) 

Otro tipo especial.de gráfico de columnas es el gráfico de columnas de desviación. Es¬ 
te tipo de gráfico es útil para dar énfasis a los años que muestran una pérdida o para señalar 
el año en que la compañía pretende estar en punto de equilibrio. Además, el gráfico se puede 
dibujar para mostrar la desviación de una media. En la figura 10.23 se muestra un ejemplo 
de un gráfico de columnas de desviación, en el cual se da énfasis a los meses que resultan 
arriba —y abajo— del promedio. 

Gráficos de barras. Dibujados horizontalmente, los gráficos de barras son similares a 
los gráficos de columnas, pero nunca se usan para mostrar una relación durante un periodo 
de años. Más bien, se usan para mostrar una o más variables en ciertas clases o categorías du¬ 
rante un periodo específico. 


Número de transacciones procesadas 
superiores o inferiores al promedio 
mensual de 65,000 


+ 20,000 



vr. gráfico se cclu.mrcds de 
desviación puede ser más eficaz 
para mostrar qué meses tienen 
transacciones superiores al 
promedio. 
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lln gráfico circular es una forma 
atractiva visualmente para 
mostrar cómo se divide el 100 
por ciento de una entrada err un. 
momento particular. 



Las barras se podrían organizar de muchas formas diferentes. Pueden estar en orden al¬ 
fabético, numérico, geográfico o progresivo. Incluso se pueden ordenar por magnitud. Por 
ejemplo, en una propuesta de sistemas, un gráfico de barras sería útil para comparar los vo¬ 
lúmenes de facturas de envíos, cuentas de cliente y las facturas de vendedores procesadas 
por el sistema de cómputo durante julio. Un gráfico de barras es uno de los formularios de 
gráficos más ampliamente conocidos y puede hacer una comparación de una forma simple. 

Gráficos circulares. Otro tipo de gráfico normalmente usado es el círculo o gráfico 
circular. Como se muestra en la figura 10.24, este gráfico se usa para presentar cómo 100 
por ciento de un artículo se divide en un periodo particular. 

Los gráficos circulares son más fáciles de leer que los gráficos de columnas apilados o 
los gráficos de barras subdivididos. Su principal desventaja es que ocupan mucho espacio en 
una página. 


PRESENTACIÓN DE LA PROPUESTA DE SISTEMAS 

Como analista de sistemas, debe entender a su público y cómo organizar, dar apoyo y reali¬ 
zar la presentación oral. 

CÓMO ENTENDER AL PÚBLICO 

Tal como el público para la propuesta escrita ayuda a determinar el estilo de la escritura, 
nivel de detalle y tipo de figuras, el público para la presentación oral ayuda al orador a des¬ 
cubrir qué tan formal ser, qué presentar y qué tipos de apoyos visuales incluir. Es indispen¬ 
sable que sepa a quién se estará dirigiendo. 

ORGANIZACIÓN DE LA PRESENTACIÓN DE LA PROPUESTA DE SISTEMAS 

Busque en los datos recopilados de la organización que se resumen en la propuesta escri¬ 
ta. Busque de cuatro a seis puntos principales que encapsulan la propuesta. En particular, 
verifique el resumen ejecutivo, la sección de recomendaciones y el resumen de la propues¬ 
ta. Si el tiempo asignado para la presentación oral es más de una hora y media, los puntos 
principales se pueden ampliar a nueve o más. 

Una vez que los puntos principales y los puntos de apoyo se aclaran, se pueden escribir 
una introducción y conclusión. Observe que la introducción se hace hasta el final, no al 
principio, debido a que ésta debe ver previamente los cuatro a seis puntos principales de la 
propuesta, los cuales no es posible determinar al principio. 

La introducción también debe incluir un "gancho", algo que conseguirá que el público 
esté intrigado con lo que sucederá después. El gancho debe ser un enfoque creativo parala 
propuesta que une directamente los intereses del público con el nuevo material presentado. 
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SE DEBE ELIMINAR ESTA GRAFICA? 


"Hey. me alegro de que los hayan contratado. Sé que los Redwlngs 
serán mejores la próxima temporada gracias a ustedes. Mi trabajo 
también será mucho más sencillo", dice Andy Skors, gerente de venta de 
boletos del equipo de hockey de Kltchener. Ontario; los Kltchener Red^ 
wlngs. Andy ha estado trabajando con el equipo de análisis, de sistemasr-, 
de usted para estudiar los requisitos de sistemas para computarlzar las 
ventas de boletos. J j' ■ j!; - 

Recuerde que la última, vez que tuvimos noticias del equipo de análi¬ 
sis de sistemas, conformado por lan Stlcklng (su líder). Rjp Shlnpadd, 
Flona Wrlnk y usted, usted estaba luchando.para apresurar el proyecto y 
establecer metas de productividad para el equipo (en la Oportunidad de 
con^ultoría 3.3). ! • t'' 

Andy está hablando con ej equipo sobre qué Incluir en la propuesta 
de sistemas para hacerla tan persuasiva como sea posible para los di-' 
rectlvos de Redwlngs. "Sé que les va a gustar este gráfico", continúa 
Andy. "Es algo que dibujé después de que usted me hizo esas preguntas 
sobre las ventas de boletos pasadas, Rlp", L5 

Andy da el gráfico de barras a Rlp. quien lo mira y .suprime una lige¬ 
ra sonrisa. "Ya que está.usted aquí con nosotros, Andy. ¿por qué.no nos : 

Como un jugador que se dirige a ejecutar un tiro penal. Andy comien¬ 
za una descripción fluida del gráfico. "Bueno, nuestras ventas de coletos- 


alcanzaron un cifra sin precedentes en 1996. Estábamos de plácemes 
ese año. Hubiera podido vender los asientos en el marcador si me lo hu-l 
bieran permitido.. Desgraciadamente, las ventas de boletos descendieron 
hasta niveles sin precedentes en 1997. Es decir, estamos hablando de 
un 1 completo desastre. Los boletos se desplazaron con más lentitud que un 
glaciar. Tuve que convencer a los jugadores de que regalaran boletos 
: cuando fueran a los centros comerciales. Porqué, simplemente mire'es¬ 
te gráfico, es terrible". • 

"Creo que el computarlzar las ventas de boletos nos ayudará a se¬ 
leccionar a nuestros seguidores durante la temporada. Tenemos qué 
averiguar quiénes son y traerlos de vuelta. Conseguir que se queden con : 
: nosotros. Ésa sería una buena meta", concluye Andy. 

. Al tiempo que Andy finaliza su presentación, lan se ve como, si la pre¬ 
sentación hubiera durado los 20 minutos que dura uno de los periodos 
del juego. Dándose cuenta de esto, Flona dice: "Gracias por los datos, 

, Andy. Veremos cómo Incluirlos en el Informe".. 

Cuando Flona y Rlp salen de la habitación con Andy, lan le pide a us¬ 
ted. el cuarto miembro del equipo, que asesore a Andy en su gráfico de 
barras y haga una lista de los problemas que haya detectado en él. A lan 
también le gustaría que esbozara algunas alternativas para grafícar los 
datos de las ventas de boletos para Incluir en la propuesta de sistemas 
I. Un gráfico correcto y persuasivo sobre estas ventas 
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Un gráfico.dibujado incorrectamente; 


PREPARACION DE LA PROPUESTA DE SISTEMAS 


| SCSllliJ i 3 347. 











Una anécdota, una analogía, una cita, una poesía o incluso un chiste pueden abrir una pre¬ 
sentación con éxito. Si se usa el humor, debe estar directamente relacionado con el tema y 
debe hacer un punto sobre lo que vendrá. 

Las conclusiones deben reflejar las introducciones. Las ideas principales se deben reite¬ 
rar y se debe dar un pensamiento de cierre (similar al gancho creativo de la introducción). 

Las preguntas se pueden hacer durante o después de la presentación. Contestar las pre¬ 
guntas durante la presentación hace una reunión más informal. Sin embargo, si hay un reto 
serio podría descarrilar la propuesta. Para mantener el control y comunicar sus puntos efi¬ 
cazmente, es permisible pedir que las preguntas se guarden hasta el final. 


PRINCIPIOS DE LA PRESENTACIÓN ORAL 

Saber quién está en el público le dirá al analista qué tan formal hacer la presentación. Si el 
CEO se incluye en la reunión, las oportunidades serán bastante formales. Si el público se 
compone de usuarios una presentación de estilo taller —un poco más informal— será más 
apropiada. Una de las mejores formas de calibrar la formalidad de presentaciones es obser¬ 
vando muchas reuniones organizacionales diferentes antes de la presentación de la propues¬ 
ta de sistemas. Las expectativas normalmente se basan en las costumbres y la cultura de la 
empresa. 

Las reglas para la presentación son básicas: 

1. Proyecte su voz lo suficientemente alta para que el público pueda oírlo. 

2. Mire a cada persona del público conforme hable. 

3. Haga los elementos gráficos suficientemente grandes como para que el público pueda 
verlos. 

4. Use gestos naturales a su estilo de conversación. 

5. Introduzca y concluya su conferencia confiadamente. 

El solo pensar en pararse frente a las personas puede poner sumamente nerviosos a los pre¬ 
sentadores; de hecho, se dice que el miedo más grande de los hombres es hablar ante un pú¬ 
blico (para las mujeres es el segundo miedo más grande). Sin embargo, si es usted mismo, si 
está preparado y si habla con naturalidad, podrá comunicar sus recomendaciones de una 
manera creíble. 



RESUMEN 

Al inventariar el equipo disponible y en orden, los analistas de sistemas podrán determinar 
mejor si será recomendado el hardware de cómputo nuevo, modificado o actual. 

El hardware de cómputo se puede adquirir a través de la compra, arrendamiento finan¬ 
ciero o alquiler. Los vendedores proporcionarán servicios de apoyo tales como el manteni¬ 
miento preventivo y capacitación de usuario que normalmente se negocian por separado. El 
software se puede crear como un producto personalizado, comprar como un paquete de soft¬ 
ware comercial (COTS) o subcontratar a un proveedor de servicios de aplicaciones (ASP). 

Con frecuencia se exige a analistas de sistemas desarrollar o evaluar paquetes de soft¬ 
ware de nivel superior usado por los sistemas de apoyo a la toma de decisiones. El analista 
puede ayudar a obtener la información necesaria para identificar los objetivos, alternativas, 
criterios, atributos y prioridades o pesos necesarios para la toma de decisiones criterios 
múltiples. 

Los tomadores de decisiones también pueden usar sistemas expertos y redes neurales 
para resolver problemas. También pueden buscar apoyo de sistemas de recomendación, los 
cuales sondean las preferencias de usuarios y llegan a los resultados por ponderación nu- 







EXPERIENCIA CON HYPERCASE® 


"Sé que es difícil ponerlo en práctica, pero usted ha estado suficiente tiempo aquí para saber 
que todos nosotros tenemos curiosidad por saber lo que ha encontrado hasta ahora. [Esta¬ 
mos especialmente interesados en lo que usted piensa de nosotros! ¿Somos una gran fami¬ 
lia feliz, o parecemos un zoológico? Ya en serio, a Snowden le gustaría que ustedi ofreciera 
una breve presentación oral de una propuesta preliminar paraiun nuevo sistema automati¬ 
zado de elaboración dg informes del prqyecto.para el Gnipode Capacitación. ¿A quién debe¬ 
mos incluir? Bueno, el señorTorrey, Dan Hill, Tom Ketcham y Snowden, por supuesto, de¬ 
searán estar allí- Veamos... aquí: en la pantalla tengo¡ el calendario ejecutivo. Todos los que 
necesitamos están libres dentro A de uña semana, el jueves alas 3:00, Puede usted traer a to¬ 
do su equipo si lo desea. Esa sala tiene capacidades multimedia, por si desea hacer algo 
atractivo, pero limítese a aproximadamente 15 minutos alo sumo. Ah, una cosa más, estoy 
seguro de que al señor Hyatt le agradará venir. [Diviértase!" :/ 

PREGUNTAS D|HYPERCASE 

1. Prepare un borrador de propuesta preliminar: para un nuevo sistema automatizado de 
elaboración de informes de;proyecto para el Grupo de Capacitación. Incluya sufi¬ 
cientes detalles como si fuera ausar su borrador corno notas del orador durante una 

presentación..,; A 

2. Use un paquete de software comoi Microsoft PowerPoint para crear úna breve presen¬ 

tación con diapositivas (de 3 a,5 diapositivas] para ilustrar la propuesta preliminar del 
sistema automatizado de elaboración de informes de proyecto que bosquejó en la pre¬ 
gunta 1. • \ ; 

3. Pida a sus compañeros de clase que actúen los roles de Warren Torrey, Dan Hill, Tom 
Ketcham y Snowden Evans (el rol del señor Hyatt es opcional). Presénteles su propuesta 
preliminar para el nuevo sistema automatizado de elaboración de informes de proyec¬ 
to. Utilice la presentación con diapositivas que generó en la pregunta 2. 

4. Escriba un informe de dos párrafos basado en la retro alimentación recibida en la pro¬ 

puesta preliminar durante la representación de roles de la pregunta 3. ¿Qué preguntas 
surgieron? ¿Qué cambios realizará? ' : 



mérica o por frecuencia. Los ejecutivos buscan información externa y hay muchas formas 
diferentes de obtener dicha información de Web. Estos métodos incluyen tecnologías de 
actualización automática, páginas de inicio personalizadas, periódicos en línea y agentes in¬ 
teligentes. Incluso la información para el apoyo a la toma de decisiones se puede colocar en 
dispositivos portátiles, teléfonos celulares y radiolocalizadores. 

Preparar una propuesta de sistemas significa identificar todos los costos y beneficios de 
diversas alternativas. El analista de sistemas tiene varios métodos disponibles para pronosti¬ 
car los costos futuros, beneficios, volúmenes de transacciones y variables económicas que 
afectan los costos y beneficios. Los costos y beneficios pueden ser tangibles (cuantificables) 
o intangibles (no cuantificables y resistentes a la comparación directa). 

Un analista de sistemas tiene muchos métodos para analizar costos y beneficios. El aná¬ 
lisis de punto de equilibrio examina el costo del sistema actual versus el costo del sistema 
propuesto. El método de análisis del tiempo de recuperación de la inversión determina el 
tiempo que tomará antes de que el nuevo sistema sea aprovechable. El análisis de flujo de 
efectivo es apropiado cuando es crítico saber la cantidad de desembolsos de efectivo, mien¬ 
tras que el análisis de valor presente toma en consideración el costo de pedir prestado el di¬ 
nero. Estas herramientas ayudan al analista a examinar las alternativas disponibles y hacer 
una recomendación bien documentada en la propuesta de sistemas. 
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El analista de sistemas debe seguir tres pasos principales para reunir una propuesta de 
sistemas eficaz: organizar eficientemente el contenido de la propuesta, escribir la propuesta 
en un estilo de negocios apropiado y presentar de forma oral una propuesta de sistemas in¬ 
formativa. Para ser eficaz, la propuesta se debe escribir de forma clara y entendible y su con¬ 
tenido se debe dividir en 10 secciones funcionales. 

Las consideraciones visuales son importantes al reunir una propuesta. Mucho de lo que 
es importante en la propuesta de sistemas puede reforzarse a través del uso correcto de ci¬ 
fras, incluyendo tablas y gráficos. Los gráficos comparan dos o más variables con el tiempo 
o en un periodo particular. A las cifras siempre las acompaña una interpretación escrita en 
la propuesta. Los gráficos y tablas que se utilizan para la planeación previa a la propuesta se 
pueden incorporar en ésta si son importantes. La presentación oral del sistema se basa en la 
propuesta escrita y es otra forma de vender el sistema eficazmente. 

PALABRAS Y FRASES CLAVE 

agente inteligente (re: la Web) 
análisis de flujo de efectivo 
análisis de punto de equilibrio 
benchmarking 
beneficios intangibles 
beneficios tangibles 
costos intangibles 
costos tangibles 
elaboración de pronósticos 
filtrado colaborativo 
gráfico circular 
gráfico de barras 
gráfico de columnas 
gráfico de líneas 
juicio gráfico 

PREGUNTAS DE REPASO 

1. Mencione los elementos que se deben incluir en un formulario de inventario del hard¬ 
ware de cómputo. 

2. ¿Qué significa el término carga de trabajo estimada? 

3. Mencione cuatro criterios para evaluar el hardware del sistema. 

4. ¿Cuáles son las tres opciones principales para la adquisición de hardware de cómputo? 

5. ¿Bajo qué condiciones es apropiado rentar el hardware de cómputo? 

6. ¿Qué significa COTS? 

7. ¿Qué significa ASP en relación con la entrega del software? 

8. ¿Cuáles son las ventajas y desventajas de crear su propio software? . 

9. ¿Cuáles son las ventajas y desventajas de comprar software COTS? 

10. ¿Cuáles son las ventajas y desventajas de subcontratar las necesidades de software con 
un ASP? 

11. Mencione las seis categorías principales para clasificar el software. 

12. ¿Qué significa AHP? 

13. ¿Cuáles son los sistemas de recomendación? 

14. ¿Cómo pueden los tomadores de decisiones obtener información externa de la Web? 

15. ¿Cuál es la diferencia entre las tecnologías de actualización automática, las páginas de 
inicio personalizadas, los periódicos en línea y los agentes inteligentes? 


método de mínimos cuadrados 
procesamiento analítico jerárquico 
(AHP) 

promedio móvil 
propuesta de sistemas 
red neural 

sistema de apoyo a la toma de 
decisiones (DSS) 
sistema experto 
sistemas de recomendación 
soporte técnico del fabricante 
tecnologías de actualización 
automática 

tiempo de recuperación de la inversión 
valor presente 
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16. ¿Por qué la elaboración de pronósticos es una herramienta útil para el analista de 
sistemas? 

17. Defina la elaboración de pronósticos incondicionales. 

18. ¿Cuál es una desventaja del juicio gráfico? 

19. ¿Cuál es el objetivo de estimar una tendencia con el método de mínimos cuadrados? 

20. ¿Por qué es útil el método de la media móvil? 

21. Defina costos y beneficios tangibles. Dé un ejemplo de cada uno. 

22. Defina costos y beneficios intangibles. Dé un ejemplo de cada uno. 

23. Mencione cuatro técnicas para comparar los costos y beneficios de un sistema propuesto. 

24. ¿Cuándo es útil el análisis de punto de equilibrio? 

25. ¿Cuáles son las tres desventajas de usar el método del análisis del tiempo de recupera¬ 
ción de la inversión? 

26. ¿Cuándo se utiliza el análisis del flujo de efectivo? 

27. Defina el análisis del valor presente. 

28. Como un lincamiento general, ¿cuándo se debe utilizar el análisis del valor presente? 

29. ¿Cuáles son los tres pasos que el analista de sistemas debe seguir para integrar una pro¬ 
puesta de sistemas eficaz? 

30. Mencione las 10 secciones principales de la propuesta de sistemas. 

31. ¿Qué relaciones ilustra un gráfico de líneas? 

32. ¿Qué relaciones ilustra un gráfico de columnas? 

33. ¿Qué relaciones ilustra un gráfico de barras? 

34. ¿Qué relaciones ilustra un gráfico circular? 

35. Mencione los cinco lincamientos para usar cifras eficazmente en la propuesta de sistemas. 

36. ¿Qué clase de material de apoyo debe incluirse en una presentación oral de la propues¬ 
ta de sistemas a un público compuesto por ejecutivos? 


1. Delicato, Inc., un fabricante de instrumentos de medición precisos parausos científicos, 
le ha presentado a usted una lista de atributos que sus gerentes consideran importantes 
para seleccionar un fabricante de hardware y software de cómputo. Los criterios no se 
muestran en orden de importancia. 

1. Precio bajo. 

2. Software escrito con precisión para aplicaciones de ingeniería. 

3. El fabricante da mantenimiento rutinario al hardware. 

4. Capacitación para los empleados de Delicato. 

a. En un párrafo, haga una crítica de la lista de atributos. 

b. Usando su entrada inicial, ayude a Delicato, Inc., a preparar una lista de criterios 
más apropiada para seleccionar fabricantes de hardware y software de cómputo. 

2. SoftWear Silhouettes es una casa de ventas por correo especializada en ropa de algo¬ 
dón, que está creciendo con rapidez. A la dirección le gustaría extender las ventas a la 
Web con la creación de un sitio de comercio electrónico. La compañía tiene dos analis¬ 
tas de sistemas y un programador de tiempo completo. Las oficinas de la compañía se 
ubican en un pueblo pequeño y aislado de Nueva Inglaterra, y los empleados que se ocu¬ 
pan del negocio de ventas por correo tradicional tienen poca capacitación en el manejo 
de computadoras. 

a. Considerado la situación de la compañía, prepare una lista de atributos de softwa¬ 
re en los cuales SoftWear Silhouettes debe poner especial cuidado al momento de 
elegir el software para crear un sitio Web e integrar el negocio de ventas por correo 
con el negocio de ventas a través del sitio Web. 

b. ¿Usted recomendaría software COTS, software personalizado o software subcon¬ 
tratado a un ASP? En un párrafo, mencione por cuál se inclinaría y las razones de 
su elección. 

c. Mencione las variables que contribuyeron a su respuesta del problema 2b. 
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3. Abajo se muestra la demanda de 10 años para YarDarts, un juego al aire libre para to¬ 
da la familia que es parte de la línea de productos de 65 juegos de Open Air, Ltd., un 
fabricante que se especializa en juegos al aire libre que se pueden practicar en un área 
pequeña. 

Año Demanda 

1994 20.900 

1995 : 31,200 

1996 28,000 

. 1997 f 41.200 ; 

1998 49,700 

1999 7 46.400 

2000 51.200 

2001 52.300 

2002. 49.200 

2003 57,600 

a. Grafique los datos de la demanda de YarDarts. 

b. Pronostique la demanda para YarDarts durante los próximos cinco años usando el 
enfoque del juicio gráfico. 

4. a. Determine la tendencia lineal para YarDarts usando el método de mínimos cua¬ 

drados. 

b. Estime la demanda para YarDarts durante los próximos cinco años usando la ten¬ 
dencia que usted haya determinado. 

5. a. Determine la tendencia lineal para YarDarts usando una media móvil de tres años. 

b. Use mínimos cuadrados en los promedios del problema 3 a para determinar una 
tendencia lineal. 

c. Estime la demanda para YarDarts durante los próximos cinco años extendiendo la 
tendencia lineal encontrada en el problema 4a. 

6. ¿Aparentan los datos de YarDarts tener una variación cíclica? Explique. 

7. Interglobal Paper Company ha pedido su ayuda para comparar su sistema de cómpu¬ 
to actual con uno nuevo que a la junta directiva le gustaría implementar. Los costos 
tanto del sistema propuesto como los del actual son los siguientes: 


Costos del sistema 

Costos del sistema 

Costos 

propuesto 

actual 

Año 1 



Arrendamiento del equipo 

$2 11OO 

! : $11,500 

Sueldos : ' 

V 3i ;ói30 

50,000 

Gastos fijos i""". : 

4,00C 

3,000 : 

Desarrollo 

; * 30*000 •: 


Año 2 



Arrendamiento del equipo 

$20,000 

$10,500 

Sueldos 

33,000 

55,000 

Gastos fijos 

4,400 

3,300 

Desarrollo 

12,000 

— 

Año 3 



Arrendamiento del equipo 

$20,000 • 

$1 0,500 a 

SueldOS 

1 36,000 > - 

- : 60 A 000 

Gastos fijos ' : ■■ 

4,900- : . 

.y..-«;* 3,60 0 : : 

Desarrollo 

'. . ... : - , 

' ;*»■■ V M 

Año 4 



Arrendamiento del equipo 

$20,000 

$10,500 

Sueldos 

39,000 

66,000 

Gastos fijos 

5,500 

4,000 

Desarrollo 

— 

— 
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a. Mediante el análisis de punto de equilibrio, determine en qué año alcanzará el 
punto de equilibrio Interglobal Paper Company. 

b. Grafique los costos y muestre el punto de equilibrio. 

8. A continuación se muestran los beneficios del sistema para Interglobal Paper Company 
(del problema 7]: 


Año 

Beneficios 

i: 1 

$55, 000 ' i 

i ,.,2 

Á¿'Á;;;75,o0ff.:.: 


.80^000 

. 4.'"' 

A : :H : 85,0(j0 Á 


a. Use los costos del sistema propuesto de Interglobal Paper del problema 7 para de¬ 
terminar el periodo de recuperación de la inversión (use el método del análisis del 
tiempo de recuperación de la inversión]. 

b. Grafique los beneficios contra los costos e indique el periodo de recuperación de la 
inversión. 

9. Glenn's Electronics, una compañía pequeña, ha establecido un servicio de cómputo. La 
tabla de abajo muestra los ingresos esperados para los primeros cinco meses de funcio¬ 
namiento, además de los costos por la remodelación de oficinas, etc. Determine el flujo 
de efectivo y el flujo de efectivo acumulado para la compañía. ¿Cuándo se espera que 
Glenn's tendrá una ganancia? 



Julio 

Agosto 

Septiembre 

Octubre 

Noviembre 

INGRESO 

$35.000 : 

$36.000 

$42,000 

$48,000 

$57,000 

COSTOS 






Remodelado de oficinas 

$25,000 

$8,000 




Sueldos 

11,000 

12,100 

$13,300 

$14,600 

$16,000 

Capacitación 

6,000 

6,000 




Arrendamiento del equipo 

8,000 

8,480 

9,000 

9,540 

10,110 

Suministros 

3,000 

3,150 

3,300 

3,460 

3,630 


10. Álamo Foods, de San Antonio, quiere introducir un nuevo sistema de cómputo para su 
almacén de productos perecederos. Los costos y beneficios son los siguientes: 


Año _ Costos _ Beneficios 

1 $33,000 $21,000 

• 2 V. 5 j 34-600 26.200 

3 36.300 32.700 

4 : >;VV 38.100 40,800 

5 40.000 : 51.000 

6 42.000 63.700 


a. Dada una tasa de descuento de 8 por ciento (.08], realice el análisis de valor pre¬ 
sente en los datos de Álamo Foods. [Sugerencia: Use la fórmula 

1 

( 1 + 0 " 

para encontrar los multiplicadores para los años 1 a 6.] 

b. ¿Cuál es su recomendación para Álamo Foods? 

11. a. Suponga que la tasa de descuento del problema 10a cambia a 13 por ciento (.13]. 
Realice un análisis de valor presente con la nueva tasa de descuento. 

b. ¿Cuál es su recomendación para Álamo Foods? 

c. Explique la diferencia entre el problema 10b y el problema 1 Ib. 
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12. Resuelva el problema 7 usando un programa de hoja de cálculo como Excel. 

13. Use un programa de hoja de cálculo para resolver el problema 9. 

14. Resuelva el problema 10 usando una función para el valor presente neto, como 
@NPV(x, rango) en Excel. 

15. "Creo que es muy justo que redacten todas las alternativas que han considerado", dice 
Lou Cite, supervisor de personal de Day-Glow Paints. "Después de todo, ustedes han 
estado trabajando durante algún tiempo en estos sistemas, y creo que a mi jefe y a to¬ 
dos los demás les interesará ver lo que ustedes han encontrado." Usted está hablando 
con Lou mientras se prepara para elaborar la propuesta del sistema final que su equipo 
presentará a la alta dirección. 

a. En un párrafo, explique a Lou por qué su propuesta no contendrá (y no debe con¬ 
tener) todas las alternativas que su equipo ha considerado. 

b. En un párrafo, discuta el tipo de alternativas que deben aparecer en la propuesta 
de sistemas final. 

16. Revisando los datos que ha recolectado para su propuesta para Linder's Machine Parts 
de Duluth, Minnesota, usted encontró un pronóstico de demanda para las partes duran¬ 
te los próximos cinco años así como el pronóstico del número de compañías que adqui¬ 
rirán las partes. A usted le gustaría incluir los datos en su propuesta de sistemas para 
apoyar su argumento de que se requiere un nuevo sistema, y las cifras que se dan actual¬ 
mente en esta descripción son las siguientes: "Las columnas muestran que la demanda 
de 120,000 aumentará a 130,000 en el año 2, subirán a 20,000 en el año 3, subirán 
a 40,000 en el año 4, y se nivelarán en el año 5. Aunque la demanda de partes continua¬ 
rá subiendo, el número total de compañías que comprarán será de 700 el año 1 y se re¬ 
ducirá a 50 compañías cada año durante los próximos cinco años". 

a. Con base en la descripción, dibuje un gráfico de barras para ilustrar la demanda 
para Linder durante los próximos cinco años. 

b. Con base en la descripción, dibuje un gráfico de columnas para ilustrar la deman¬ 
da para Linder durante los próximos cinco años. 

c. Con base en la descripción, dibuje un gráfico de barras para mostrar el declive en 
el número total de compañías que pedirán partes de máquinas a Linder. 

d. Con base en la descripción, dibuje un gráfico de líneas para ilustrar tanto el au¬ 
mento en la demanda como la disminución en el número total de compañías que 
adquirirán las partes. 

17. "Estaba pensando cómo manejaré mi parte de la presentación a la dirección", dice Mar- 
garet, un miembro de su equipo de análisis de sistemas. "Aunque algunos de ellos nos 
dijeron que 'no están al tanto de los avances en las computadoras', creo que necesitan 
conocer los aspectos técnicos de nuestro sistema recomendado; de otra manera quizá 
no lo acepten. Así que empezaré por definir términos básicos como 'byte' y 'código del 
programa', y así convertiré la reunión en un breve tutorial sobre computación. ¿Qué 
piensa?" 

a. En un párrafo, critique el enfoque de Margaret para la presentación de la propues¬ 
ta de sistemas al público de ejecutivos. 

b. En un párrafo, sugiera una manera diferente de acercarse a un público de ejecuti¬ 
vos para la presentación de la propuesta de sistemas. Asegúrese de incluir tipos de 
apoyos —y temas— más apropiados que aquellos que Margaret tiene en mente. 
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ALLEN SCHMIDT, JULIE E. KENDALL Y KENNETH E. KENDALL 

LA PROPUESTA DE SISTEMAS 


"Debido a que escogimos diseñar e implementar el nuevo sistema de cómputo con PCs en¬ 
lazadas en una red de área local, deberíamos empezar a preparar la propuesta de sistemas", 
sugiere Anna. Ella y Chip se reúnen para planear la próxima fase del diseño. 

"Sí", contesta Chip. "Necesitamos tomar algunas decisiones de hardware y software, así 
como también aseguramos de que los usuarios están conscientes de los beneficios que el 
nuevo sistema proporcionará". 

"Debemos determinar qué software se necesitará para implementar el sistema y los re¬ 
querimientos de hardware para cada usuario del sistema", observa Anna. "¿Por qué no tra¬ 
bajas en la parte del hardware y me dedico al software?" 

"Claro", contesta Chip. "Planeo reunirme nuevamente con cada uno de los usuarios. 
Cuando tenga toda la información, haré un informe resumido". 

Chip comienza a trabajar con cada usuario para determinar qué equipo se requerirá. 
Algunos de sus resultados son los siguientes: 

Míke Crowe tiene una computadora de escritorio con procesador Pentium 4 de 3 GHz. 
Esta computadora es más que suficiente para las necesidades del nuevo sistema. El equipo 
adicional y necesario es una computadora portátil para crear las transacciones al realizar un 
inventario físico y el trabajo de mantenimiento preventivo. 

Dot Matricks tiene una computadora de escritorio con procesador Pentium 4 de 2.53 GHz 
y emulación de terminal de mainframe. Esta computadora es adecuada para el nuevo sistema. 

Ian Perteks tiene una computadora portátil con procesador Pentium 4 de 2.40 GHz con 
una tarjeta de red inalámbrica. Esta computadora es adecuada para el nuevo sistema. 

Paige Prynter tiene una computadora de escritorio con procesador Celeron de 1.80 GHz. 
Se recomienda reemplazarla por una computadora con procesador Pentium de 3 GHz. Agre¬ 
gar software para ejecutar la emulación de terminal en la nueva computadora. 

CherWare tiene una computadora más vieja con procesasdor Celeron de 1.20 GHz. Se 
recomienda actualizarla con procesador Pentium de 3.0 GHz. 

Otros equipos y suministros: una computadora servidor para manejar la red debe ser 
Pentium de 2.60 GHz o superior, con taijetas para comunicaciones. Se deben proporcionar 
una impresora láser de gran velocidad que se conecte directamente al servidor, al igual que 
impresoras láser o de inyección de tinta más pequeñas que se conecten a cada computado¬ 
ra. Además, se debe comprar cable para conectar a cada usuario a la red. 

Mientras tanto, Anna está determinando el software que se necesitaría para implementar 
el sistema. Debido a que cada uno de los usuarios recibirá software desarrollado por progra¬ 
madores, la tarea principal es decidir qué software se necesitará para el desarrollo del sistema 
y para conectar en red las computadoras. Después de investigar las opciones del software, 
Anna hace las siguientes recomendaciones: 

1. Software de desarrollo para crear el sistema. Existen tres opciones: 

a. Utilizar C++ para escribir el software de aplicación. La ventaja de C++ es que ac¬ 
tualmente lo emplean los miembros del personal de programación y es orientado a 
objetos. 

b. Usar un paquete de base de datos y escribir código orientado a objetos. Compilar 
los programas de base de datos en código ejecutable. Actualmente, Access está dis¬ 
ponible en los laboratorios para estudiantes. Se deben evaluar otros paquetes de 
base de datos. 

c. Construir una solución cliente/servidor y para la Web. Visual Basic, .NET y Java 
son muy poderosos y funcionan con diferentes bases de datos. 
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2. Se necesita software de red para establecer y facilitar el manejo de la red de área local 
con pantallas de interfaz gráfica de usuario. 

Chip y Anna se reúnen para examinar los resultados. 

"Supongo que la siguiente tarea es obtener los precios del hardware y el software selec¬ 
cionados", dice Anna. "¿Cuál crees que es nuestra mejor fuente de información de precios?" 

"Hay varias fuentes de información", contesta Chip. "Podríamos investigar en la Web o 
examinar las revistas de comercio. Hay muchas casas de ventas por correo que quizá anun¬ 
cien los precios, a menudo con un descuento en Internet. También debemos llamar o visitar 
a distribuidores y obtener cotizaciones, sobre todo con descuentos educativos. Los fabricantes 
podrían tener programas especiales. También verificaremos con el encargado de las adquisi¬ 
ciones de la universidad. Una vez que tengamos toda la información de precios, podemos 
elaborar un documento como parte de la propuesta de sistemas." 

EJERCICIOS 

E-l. Investigue en revistas de cómputo los precios de las máquinas y los dispositivos peri¬ 
féricos que se tienen que adquirir. Haga una lista de comparación para cada máquina. 

E-2. Visite una tienda local de menudeo de computadoras y obtenga información sobre el 
precio de cada computadora mencionada en este episodio. Incluya impresoras y mo¬ 
nitores (mínimo de 17 pulgadas] de alta resolución. Haga una lista de comparación 
para cada máquina. 

E-3. Busque en la Web tiendas por Internet o minoristas de computadoras y obtenga infor¬ 
mación sobre el precio de cada computadora mencionada en este episodio. Incluya 
impresoras y monitores de alta resolución. Haga una lista de comparación para cada 
máquina. 

E-4. Examine las revistas de comercio y resuma sus resultados, comparando tres paquetes 
de base de datos diferentes, sus características y precios. 

E-5. Investigue las características y precios de los paquetes de C++. Haga una lista de sus 
resultados. 

E-6. Investigue las características y precios de los paquetes de base de datos. Haga una lis¬ 
ta de sus resultados. 

E-7. Investigue las características y precios de Visual Basic, .NET y Java. Haga una lista de 
sus resultados. 

E-8. Busque en la Web información sobre las características de tres de los paquetes de soft¬ 
ware mencionados anteriormente. Haga una lista de sus resultados. 

E-9. Calcule el costo total para las tres únicas soluciones usando la información recopilada 
en los ejercicios anteriores. 
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PREPARACION DE LA PROPUESTA DE SISTEMAS 















OBJETIVOS DE APRENDIZAJE 


Una vez que haya dominado el material de este capitulo, podrá: 

1. Entender los objetivos para el diseño eficaz de la salida:: 

2. Relacionar el contenido de la salida con los metodos .de salida. 

3. Comprender como afecta el sesgo de la salida a los usuarios. 

' 4. Diseñar la salida en pantalla. ./•. ; v V' . .r : . ...■; 

5. Diseñar la salida en forma de tabla y gráfica para los sistemas de apoyo a la toma de decisiones. 

6. . Diseñar un sitio Web para comercio electrónico. , 


1.a salida es la inlbrmauon que si- entrega a las usuario.: a través del sistema de ¡nformadón. 
ütili/ando inlranels, etfranels o la World Wide Web Algunos dalos requieren ’.ina j^ran t.anu- 
dad di 1 procesamiento antes di- translórmarse en la salida apropiada: otros se almacenan, y 
(..•liando se recuperan, se consideran cdmú calida Con puro o ningún prw.: cs : amicnta La salida' 
puede lomar muchas formas: los informes impresos tradicionale.-? y los informes presentados 
dé manera transitoria, tomo en el caso de las pantallas de computadora: las microlórmns y 
la salida de audio.' 1„ os usuarios dependen de la salida para realizar sus tareas'V con Frecucnira 
¡u K¡in ei valor de. un sistema, sólo por su salida. I'ara crear la salida más útil po-illle. el aña- 
lista de sistemas trabaja de cerca con el usuario en un proceso interactivo hasta que el resul¬ 
tado se considera satislai-torio. 


OBJETIVOS DEL DISEÑO DE LA SALIDA 


Debido a qüe una salida útil es esencial para asegurar el uso y aceptación del sistema de 
intúrmáción, son varios los.objetivos que eJ analista de sistemas debe tener en mónte al 
diseñarla: Aquí mencionamos seis objetivos: . .. • " 

1. Diseñar la salida para satisfacer un propósito específico. \' : 

2. Hacer significativa la salida para el usuario.:’ ■■■'•.’(y;..-. 

■ 3. t.niregar la cantidad adecuada de salida: 

Proporcionar una distribución adecuada de la salida. 

^5':;.Proporcionarla salida a tiempo. il^;¡ ;; ;rí[?;i;:^ijí:ji-J - 1 ; ílijS 

. (i.' Kle§iir el método de salida más electiva: vMF 
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DISEÑO DE LA SALIDA PARA SATISFACER UN PROPÓSITO ESPECÍFICO 


Toda la salida debe tener un propósito. No es suficiente poner a disposición de los usuarios 
un informe, una pantalla o una página Web sólo porque la tecnología permite hacerlo. Du¬ 
rante la fase de determinación de los requerimientos de información, el analista de sistemas 
averigua qué propósitos se deben satisfacer. A continuación diseña la salida con base en 
esos propósitos. 

Usted verá que tiene numerosas oportunidades de proporcionar salida simplemente 
porque la aplicación le permite hacerlo. Sin embargo, recuerde la regla del propósito. Si la 
salida no es funcional, no debe crearse, porque toda salida del sistema representa costos de 
tiempo y recursos. 

DISEÑO DE SALIDA PARA SATISFACER AL USUARIO 

En un sistema de información grande que atiende a muchos usuarios con muchos propósitos 
diferentes, a menudo es difícil personalizar la salida. Con base en las entrevistas, las observa¬ 
ciones, los costos y tal vez los prototipos, será posible diseñar una salida que satisfaga lo que 
muchos usuarios, si no es que todos, necesitan y prefieren. 

En términos generales, es más práctico crear salida específica para el usuario, o que él 
pueda personalizar, cuando ésta se diseña para un sistema de apoyo a la toma de decisiones 
u otras aplicaciones sumamente interactivas, como las que se desarrollan para la Web. Sin 
embargo, aun así es posible diseñar salidas que satisfagan una función del usuario en la or¬ 
ganización, lo cual nos lleva al siguiente objetivo. 

ENTREGA DE LA CANTIDAD ADECUADA DE SALIDA 

Más no siempre es mejor, en particular cuando se trata de la cantidad de salida. La decisión 
sobre qué cantidad de salida es correcta para los usuarios forma parte de la tarea del diseño 
de la salida. 

Un heurístico útil consiste en que el sistema debe proporcionar lo que cada persona 
necesita para completar su trabajo. Sin embargo, esta respuesta aún está lejos de ser una so¬ 
lución total, porque podría ser conveniente desplegar un subconjunto de esa información al 
principio y después proporcionar al usuario una manera de acceder fácilmente a informa¬ 
ción adicional. 

El problema referente a la sobrecarga de información es tan predominante que se ha 
vuelto un cliché, pero sigue siendo una preocupación válida. No se le da un buen servicio 
a nadie si se ofrece información excesiva sólo para hacer alarde de las capacidades del siste¬ 
ma. Siempre tenga en cuenta a los tomadores de decisiones. A menudo ellos no necesitarán 
grandes cantidades de salida, especialmente si hay una manera fácil de acceder a más infor¬ 
mación a través de algún hipervínculo o una característica de extracción de información. 

ASEGÚRESE DE QUE LA SALIDA ESTÉ DONDE SE NECESITA 

A menudo la salida se produce en un lugar [por ejemplo, en el departamento de procesamien¬ 
to de datos) y después se distribuye al usuario. El aumento de la salida en línea, desplegada en 
pantalla, que se puede acceder de manera individual, ha reducido en parte el problema de la 
distribución, pero la distribución apropiada continúa como un objetivo primordial para el 
analista de sistemas. Para que sea usada y que sirva de algo, la salida se debe presentar al usua¬ 
rio correcto. No importa qué tan bien diseñados estén los informes, si no llegan a los tomado¬ 
res de decisiones que los requieren, no tienen valor. 

SUMINISTRO DE LA SALIDA A TIEMPO 

Una de las quejas más comunes de los usuarios es que no reciben la información a tiempo 
para tomar las decisiones necesarias. Aunque el tiempo no lo es todo, representa una parte 
importante de la utilidad que tendrá la salida para los tomadores de decisiones. Muchos in¬ 
formes son requeridos en forma diaria, algunos sólo mensualmente, otros anualmente y 
otros pocos sólo de manera ocasional. El uso de salida bien publicada y basada en la Web 




también puede solucionar en parte el problema de la distribución a tiempo de la salida. La 
entrega a tiempo de la salida puede ser crucial para las operaciones de negocios. 

ELECCIÓN DEL MÉTODO DE SALIDA CORRECTO 

Como se mencionó antes, la salida puede tomar muchas formas, incluyendo informes impre¬ 
sos, información en pantalla, audio con sonidos digitalizados que simulan la voz humana, 
microformas y documentos Web. Elegir el método de salida correcto para cada usuario es 
otro de los objetivos que deben tomarse en el diseño. 

En la actualidad, gran parte de la salida aparece en las pantallas de las computadoras 
y los usuarios tienen la opción de imprimirla con su propia impresora. El analista necesita 
reconocer los pros y contras al elegir un método de salida. Los costos difieren; para el usuario, 
también hay diferencias en la accesibilidad, flexibilidad, durabilidad, distribución, posibilida¬ 
des de almacenamiento y recuperación, transportabilidad e impacto global de los datos. Por 
lo general, la elección de los métodos de salida no se debe tomar a la ligera, ni tampoco se 
puede determinar de antemano. 

RELACÍfiNDELCONfENÍDO DE SALIDA CON EL MÉTODO DE SALIDA 

Es importante considerar que el contenido de la salida de los sistemas de información está 
interrelacionado con el método de salida. Siempre que diseñe la salida, necesita pensar 
cómo influirá la función en la forma y cómo influirá el propósito que pretenda conseguir en 
el método de salida que elija. 

La salida se debe pensar de una forma general a fin de que cualquier información pro¬ 
ducida por el sistema de cómputo que de alguna forma sea útil para las personas se pueda 
considerar salida. La salida se puede clasificar en externa (la que sale del negocio], tal como 
la información que aparece en la Web, o en interna (que permanece dentro del negocio], tal 
como el material disponible en una intranet. 

La salida externa es familiar para usted a través de las facturas de empresas de servicios 
públicos, anuncios, recibos de nómina, informes anuales y un sinfín de comunicaciones que 
las organizaciones tienen con sus clientes, distribuidores, proveedores, industria y com¬ 
petidores. Alguna de esta salida, tal como las facturas de empresas de servicios públicos, es 
diseñada por el analista de sistemas para atender una doble función, pues además son docu¬ 
mentos de respuesta (cuando se utilizan para el pago de los servicios facturados]. La figura 
11.1 es una factura de gas que es un documento de respuesta para el procesamiento de datos 
de una compañía de gas. La salida para una fase del procesamiento se vuelve la entrada para 
la siguiente fase. Cuando el cliente devuelve la parte designada del documento, ésta se exa¬ 
mina con un dispositivo óptico y se usa como entrada para la computadora. 

La salida externa difiere de la interna en su distribución, diseño y apariencia. Muchos 
documentos externos deben incluir instrucciones para el receptor con el fin de que éste los use 
correctamente. Muchas salidas externas se ponen en formularios impresos previamente o 
en sitios Web que llevan el logotipo y colores de la compañía. 

Las salidas internas incluyen diversos tipos de informes para los tomadores de decisiones, 
que van desde breves informes de resumen hasta informes largos y detallados. Un ejemplo 
de un informe de resumen es aquel que resume los totales de las ventas mensuales. Un 
informe detallado podría proporcionar las ventas semanales de cada vendedor. 

Otros tipos de informes internos incluyen informes históricos e informes de excepción 
que sólo se manifiestan como salida en el momento en que ocurre una situación ocasional. 
Ejemplos de informes de excepción son una lista de todos los empleados sin faltas en el 
año, una lista de todos los vendedores que no alcanzaron a cumplir con su cuota de ventas 
mensuales o un informe de las quejas de clientes hechas en los últimos seis meses. 

TECNOLOGÍAS DE SALIDA 

Se necesitan diferentes tipos de tecnologías para producir diferentes tipos de salida. Para la 
salida impresa, las opciones incluyen una variedad de impresoras. Para la salida en pantalla, 
las opciones incluyen monitores integrados a computadoras o independientes. La salida de 
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audio se puede amplificar en un altavoz o se puede escuchar a través de las bocinas de una 
PC. La salida electrónica se crea con herramientas de software especiales. Como puede ver, 
hay varias opciones. La figura 11.2 compara los métodos de salida. 

Impresoras Debido a que los informes impresos constituyen un tipo común de salida, 
es lógico asumir que en cualquier organización grande hay muchas impresoras. Aunque 
otros tipos de salida están ganando popularidad, probablemente las empresas seguirán utili¬ 
zando salida impresa o tendrán que diseñar salida que tenga un buen aspecto si los clientes, 
proveedores o vendedores la imprimen usando su propio software y hardware. 

La tendencia en las impresoras va en dirección de mayor flexibilidad. Esta tendencia se 
traduce en ampliar las opciones para la ubicación del sitio de impresión, dar cabida a diferen¬ 
tes cantidades de caracteres por página, incluir diversos estilos y tamaños de letra, cambiar 
la posición de la impresión en la página, incluir más capacidad gráfica (incluyendo el uso de 
color], imprimir silenciosamente, reducir la necesidad de almacenar la cantidad de formularios 
preimpresos, simplificar las tareas del operador del equipo de impresión y reducir la necesi¬ 
dad de intervención de un operador en el proceso. 

Junto con los usuarios, el analista de sistemas debe determinar el propósito para la im¬ 
presora. Una vez que se establece, se deben tener en cuenta tres factores principales de las 
impresoras: 

1. Confiabilidad. 

2. Compatibilidad con software y hardware. 

3. Soporte técnico del fabricante. 

Monitores como dispositivos de salida Los monitores, o pantallas de despliegue, son una 
tecnología de salida cada vez más popular. Principalmente usadas para la entrada de datos, 
las pantallas también constituyen una tecnología factible para muchos otros usos conforme 
su tamaño y precio disminuyen y conforme aumenta su compatibilidad con otros compo¬ 
nentes del sistema. 

Las pantallas tienen ciertas ventajas sobre las impresoras debido a su bajo nivel de rui¬ 
do y potencial para la interacción del usuario. En este último aspecto, la salida de pantalla 
puede ofrecer flexibilidad al permitir al usuario cambiar la información de salida en tiempo 
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real a través de la eliminación, incorporación o modificación de algunos componentes del 
informe. Las pantallas también permiten la revisión de salida almacenada y el despliegue 
de elementos de una base de datos, lo cual contribuye a que los tomadores de decisiones 
individuales no tengan que guardar informes redundantes. 


FIGURA 


Comparación de. los métodos 


de salida. 


Vídeo, audio y animación Muchas de las herramientas y paquetes de aplicaciones con los 
que estará trabajando facilitan la inclusión de vídeo en las opciones de salida. El vídeo es un 
tipo complejo de salida, ya que combina la fuerza y el potencial impacto emocional del au¬ 
dio [incluyendo efectos de sonido, voz y música) con un canal visual. Algunas aplicaciones 
familiares son aquellas que se basan en Web. Examine la figura 11.3 para ver una página 
Web que proporciona una serie de seis breves clips de vídeo de un evento real, el Knowledge 
Bowl (Torneo del Conocimiento) del Decisión Sciences Institute (DSI). Aquí es útil la salida 
de vídeo, porque el evento fue celebrado para conmemorar un aniversario importante en 
la historia de la organización. 

Hay muchos usos para incluir la salida de vídeo en las pantallas de sus usuarios. Los 
clips de vídeo constituyen salida útil para: 

1. Complementar la salida estática e impresa. 

2. Colaboración a distancia que conecta a personas que no se ven a menudo. Por ejemplo, 
puede ser útil para miembros de equipos virtuales que deben trabajar juntos, pero que 
normalmente no se reúnen en persona. 
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FIGURA 113 

Transmitir un vídeo se puede 
usar eficazmente para contar 
una historia o compartir un 
evento. Esta página Web 
describe un evento llamado 
el DS1 Knowledge Bowl 
(www.thekendalls.org/dsi-bowl). 
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3. Mostrar cómo desempeñar una acción, tal como demostrar cómo se debe llenar un formu¬ 
lario, cómo se debe instalar el software o cómo se debe ensamblar un producto. 

4. Proporcionar cursos de capacitación breves para dar énfasis a una habilidad nueva o 
poco familiar. 

5. Grabar un evento real para su análisis posterior. 

6. Conservar una ocasión importante para agregar a la memoria de una organización. 

En cierto modo, la salida de audio se puede pensar como lo contrario de una salida im¬ 
presa. La salida de audio es transitoria, mientras que una palabra impresa es permanente. Por 
lo general, la salida de audio va dirigida a un solo usuario, mientras que la salida impresa con 
frecuencia se distribuye ampliamente. El oído humano interpreta la salida de audio como 
voz, aunque en realidad se produce mediante sonidos digitales discretos que después se 
conjuntan de tal manera que se perciben como palabras continuas. Las compañías telefóni¬ 
cas fueron de las primeras empresas en producir sistemas que usan salida de audio para sus 
clientes. 

El sonido también puede mejorar una presentación. La música y los efectos de sonido 
de dominio público se pueden acceder con facilidad. Los paquetes de presentaciones como 
Microsoft PowerPoint permiten que los usuarios incluyan sonido, música e incluso vídeos. 
Los archivos de sonido tienen distintos formatos, pero algunos de los más comunes para 
PCs son los archivos .WAV que se pueden reproducir en Microsoft Windows. 

La salida de audio se está usando para "operar" los teléfonos de empresas de ventas por 
catálogo 24 horas al día, siete días a la semana. Al usar un teléfono digital, los clientes pue¬ 
den marcar el número y, en respuesta a las instrucciones mediante salida de audio, teclear el 
número del artículo, la cantidad, el precio y el número de su tarjeta de crédito. Las tiendas 
captan ventas que de otra manera se perderían, debido a que contratar empleados reales po¬ 
dría ser demasiado caro para justificar un servicio las 24 horas. 

La animación es otro tipo de salida que se puede usar para mejorar un sitio Web o una 
presentación. La animación es la presentación de diferentes imágenes en serie, una a la vez. 
Las imágenes de animación están compuestas de varios elementos básicos. Los símbolos ele¬ 
mentales pueden ser objetos abstractos o fotografías reales y se pueden usar en diferentes 
colores, tipos y texturas. La orientación espacial permite al usuario comprender si los símbo- 
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música y vídeo en movimiento, de modo que, como un medio de salida, proporcionan a un 
diseñador la creatividad máxima. 

El DVD (disco versátil digital) se está volviendo rápidamente una tecnología de salida 
útil. Un DVD tiene más capacidad que un CD-ROM y una unidad de DVD puede leer tanto 
CD-ROMs como DVDs. Los DVDs no sólo se usan para salida, sino también para almace¬ 
namiento auxiliar. 

Salida electrónica Muchos de los nuevos sistemas basados en Web que diseñe tendrán la 
capacidad de enviar salida electrónica en forma de correo electrónico, faxes y mensajes de 
boletines electrónicos que se pueden transmitir de una computadora a otra sin necesidad 
de imprimirse. 

El correo electrónico se puede establecer y operar internamente en la organización a 
través de una intranet o se puede establecer a través de compañías de comunicación o pro¬ 
veedores de servicio en línea como America Online (AOL). Al diseñar sistemas de correo 
electrónico, puede apoyar la comunicación a lo largo de la organización. Un sistema de 
correo electrónico útil y flexible puede constituir un apoyo para los grupos de trabajo. 

Se están diseñando para las organizaciones dos grupos nuevos de tecnologías que 
permiten a usuarios obtener la información de Web y también permiten a organizacio¬ 
nes enviar información periódicamente a ellos. Estas tecnologías de salida se llaman tec¬ 
nologías de demanda [pulí technology) y tecnologías de actualización automática [push 
technology), y reflejan la forma en que usuarios y organizaciones buscan información en 
Web y la "demandan" en descargas o la reciben en una "actualización automática" de los 
datos. 

Tecnología de demanda Una tecnología de salida importante hecha posible por Web es 
la tecnología de demanda. Si ha intentado obtener la información de Web haciendo clic en los 
vínculos, ha usado el tipo más básico de tecnología de demanda. La figura 11.4 muestra una 
página Web para una organización internacional de investigación en sistemas de informa¬ 
ción. Cuando cada problema está completo, OASIS, la hoja informativa de la organización, 
se pone en el sitio Web de la organización y los miembros de la asociación pueden obtener¬ 
la de Web viéndola como un documento de Adobe Acrobat. 
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Este tipo de tecnología de demanda tiene varias ventajas comparadas con enviar la sali¬ 
da como una hoja informativa de papel simple. Por ejemplo, siempre que la hoja informativa 
esté completa, se puede poner en Web; no hay retraso en la entrega. Además, si el usuario tie¬ 
ne una impresora a color, se pueden obtener copias a color, mientras que reproducir la hoja 
informativa en color en el papel para todos los miembros es prohibitivamente caro para una 
organización no lucrativa. 

En el futuro, los agentes evolutivos (programados usando software de agente inteligen¬ 
te] se podrían usar para ayudar a miembros organizacionales a encontrar lo que necesitan 
en Web. Estos agentes aliviarán un poco la carga típica de los usuarios al buscar en Web, de¬ 
bido a que los agentes observarán y entenderán el comportamiento de los usuarios cuando 
interactúen con una variedad de material en Web y después se programarán para buscar la 
información que los usuarios necesiten. Además, las búsquedas en Web serán más eficientes 
y más eficaces para los usuarios, debido a que el uso de un agente evolutivo que observe el 
comportamiento del usuario y personalice las búsquedas en Web de manera correspon¬ 
diente, puede satisfacer los resultados de las búsquedas. 

Tecnologías de actualización automática Otro tipo de salida que los analistas diseñan es el 
contenido inalámbrico y de Web entregados mediante la tecnología de actualización auto¬ 
mática. La tecnología de actualización automática se puede usar en la comunicación externa 
para actualizar automáticamente (enviar electrónicamente] la información solicitada o no 
solicitada por un cliente. También se puede usar dentro de la organización para que un em¬ 
pleado o un tomador de decisiones que están enfrentando una fecha tope critica le preste 
atención inmediata. El término de tecnología de actualización automática se puede describir 
como cualquier contenido enviado a usuarios en momentos específicos, desde la difusión bá¬ 
sica hasta la entrega de contenido selectivo usando agentes sofisticados de filtrado evolutivo. 

Muchos negocios tradicionales así como también los basados en Internet están experi¬ 
mentando con la tecnología de actualización automática. La salida de la figura 11.5 es un 
ejemplo de tecnología de actualización automática usada para distribuir una hoja informa¬ 
tiva electrónica acerca de la tecnología de información, llamada Woody's Windows Watch, 
a los suscriptores vía correo electrónico. Observe que el diseño de la página, incluyendo 
una variedad de fuentes, usos estratégicos de color y escritura atractiva, emula intencional¬ 
mente la apariencia de una página Web aunque se entrega vía correo electrónico. Esta hoja 
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La tecnología de actualización 
automática se usa para.distribuir 
información a usuarios. En 
este ejemplo, la carta Informativa 
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mediante correo electrónico 
pero es muy parecida a una; 
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informativa particular proporciona el texto completo del material en el correo electrónico 
e incrusta vínculos a URLs que envían al usuario a otros sitios Web útiles y productos re¬ 
levantes. 

La tecnología de actualización automática también puede hacer llegar la información a 
la persona que la necesita. Transmitir la información a todos los empleados es menos caro 
que imprimirla y después distribuirla a unos cuantos. Aunque en este caso los gerentes no ne¬ 
cesitan preocuparse por si un empleado particular debe o no recibir un informe, el analista 
debe tener cuidado de no enviar a los empleados información actualizada automáticamen¬ 
te sin sentido. 

Al trabajar con las tecnologías de actualización automática, se sorprenderá de su fle¬ 
xibilidad comparada con la salida en papel. Cuando los datos se entregan desde una intra¬ 
net a una PC, el usuario puede tomarlos y personalizarlos de muchas formas. Por ejemplo, 
un empleado podría decidir mirar un solo producto o generar un gráfico de ventas con el 
tiempo. 

Muchas organizaciones están experimentando con la tecnología de actualización auto¬ 
mática. La empresa National Semiconductor agregó su propio canal a un Webcaster que 
incluye tres tipos de información relacionada al producto. Wheat First Securities usó un 
Webcaster diferente para entregar la información a sus agentes de bolsa. El grupo de ope¬ 
raciones en red de MCI usa otro Webcaster comercial para enviar información sobre alertas 
de fallas a los 7,000 empleados que operan su red a larga distancia. 


FACTORES A CONSIDERAR CUANDO SE SELECCIONE LA TECNOLOGÍA DE SALIDA 

Como puede deducir de esta breve explicación de la tecnología de salida, hay varios facto¬ 
res por considerar al elegir la más adecuada. Aunque la tecnología cambia rápidamente, 
ciertos factores de uso permanecen constantes en los avances tecnológicos. Estos factores, 
algunos de los cuales presentan pros y contras, se deben considerar. Incluyen lo siguiente: 

1. ¿Quién usará (verá) la salida de datos? 

2. ¿Cuántas personas necesitan la salida? 

3. ¿Dónde se necesita la salida (distribución, logística)? 

4. ¿Cuál es el propósito de la salida? 

5. ¿Cuál es la velocidad con que se necesita la salida? 

6. ¿Con qué frecuencia se accederá a la salida? 

7. ¿Cuánto tiempo se almacenará la salida? 

8. ¿Bajo qué regulaciones especiales se produce, almacena y distribuye la salida? 

9. ¿Cuáles son los costos iniciales y finales del mantenimiento y suministro? 

10. ¿Cuáles son los requerimientos ambientales (absorción del ruido, temperatura controla¬ 
da, área para el equipo, cableado y proximidad a transmisores inalámbricos o puntos de 
acceso ("zonas activas")) para las tecnologías de salida? 

Examinar por separado cada factor le permitirá ver las interrelaciones y cómo podrían in¬ 
tercambiarse entre sí en un sistema particular. 


¿Quién usará (verá) la salida de datos? Es importante descubrir quién usará la salida 
porque los requerimientos del trabajo ayudan a decidir qué método de salida es adecua¬ 
do. Por ejemplo, cuando los gerentes de distrito deben estar fuera de sus oficinas por pe¬ 
riodos largos, necesitan la salida impresa que pueden llevar con ellos o la tecnología para 
poder acceder a los sitios Web apropiados y bases de datos cuando visitan a los gerentes 
en su región. La salida de pantalla o documentos Web interactivos son excelentes para 
personas tales como despachadores de flotillas de camiones que están en escritorios por 
largos periodos. 

Los receptores externos de salida (clientes, vendedores y proveedores, accionistas y 
agencias reguladoras) y los usuarios internos del negocio requerirán diferente salida. Los 
clientes, vendedores y proveedores pueden ser parte de varias extrañéis, las cuales son redes de 
computadoras construidas por la organización, que proporcionan aplicaciones, procesa¬ 
miento e información para los usuarios en la red. 
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Al diseñar un sitio Web es 


importante elegir una metáfora 
que se pueda usar a través del 
sitio. Este ejemplo de Merchants 
Bay (www.merchantsbay.TV) 
usa un tema marino. 


Examine el sitio Web que se muestra en la figura 11.6 para una compañía de comercio 
electrónico llamada Merchants Bay. El diseñador Web se adapta claramente a los usuarios 
esperados del sitio de venta de regalos al por mayor. El sitio Web de la compañía de comer¬ 
cio electrónico es operado por un algoritmo de negociación patentado en el cual los usuarios 
proponen ofertas (para un artículo o 400) en una serie de mercancías, llamadas "cosas bue¬ 
nas" por el presidente de la compañía. La estrategia de la compañía se basa en la experiencia 
personal del presidente con los mercados de artículos usados y la observación de que las per¬ 
sonas tienen una atracción poderosa hacia regatear por ofertas. 

El sitio Web ha elegido, intencionalmente, un diseño que se percibe como desordena¬ 
do, similar a lo que uno consigue al atravesar un mercado. El sitio está orientado a clientes 
que frecuentarían los mercados de artículos de segunda mano: se conocen como los colec¬ 
cionistas, sociables y curiosos por naturaleza. El sitio Web es una profusión de colores, in¬ 
cluye una variedad de señales de venta en una combinación de letreros e incluso incorpora 
un vídeo que proporciona nuevas capas de color y acción. Se emplea un lenguaje coloquial 
a lo largo del sitio. 

Observe que el eslogan de la compañía es "proveedor de cosas buenas". El diseñador 
Web ha realizado exitosamente una metáfora náutica a lo largo del sitio. Por ejemplo, el 
usuario es invitado a "buscar en la bahía" para ver la mercancía. Además, el logotipo de la 
compañía incluye una ola y un sol en el horizonte; y un icono de una rueda de timón se pone 
sobre una columna que invita al usuario a "navegar" por los productos, servicios y servicio al 
cliente. 

Para completar una transacción en el sitio, un cliente tiene la oportunidad de aceptar el 
"precio del Capitán" o de proponer una oferta. Si la oferta propuesta es demasiado baja de 
acuerdo con el algoritmo de negociación almacenado, se devuelve una respuesta en una 
ventana: "Gracias por su oferta, compañero. No tiene que desprenderse de su dinero si no 
quiere, ¿eh? Sin embargo, aún me agrada, compañero. Por favor intente una vez más ofrecer 
un mejor precio o pedir una cantidad mayor de artículos". De esta manera, la oferta se re¬ 
chaza de forma amistosa y cómica, y los oferentes incluso reciben dos sugerencias de cómo 
mejorar las oportunidades de que sus próximas ofertas sean exitosas. Está claro que al dise¬ 
ñar el sitio el diseñador Web tenía en mente un perfil sólido del cliente deseado. 


















¿Cuántas personas necesitan la salida? La opción de tecnología de salida también depende 
de cuántos usuarios necesitan la salida. Si muchas personas necesitan salida, probablemente la 
mejor opción sería ofrecerla en documentos basados en Web o copias impresas. Si un so¬ 
lo usuario necesita la salida, tal vez serían más adecuados una pantalla o audio. 

Si muchos usuarios del negocio necesitan diferente salida en diferentes momentos por 
periodos cortos y la necesitan con urgencia, una posible opción es usar documentos Web o 
pantallas conectadas a terminales en línea que pueden acceder a los contenidos de la base 
de datos. 

¿Dónde se necesita la salida (distribución, logística)? Otro factor que influye en la op¬ 
ción de tecnología de salida es el destino físico de la salida. La información que permanece¬ 
rá cerca de su punto de origen, que tan sólo será utilizada por unos cuantos usuarios en el 
negocio y que se podría almacenar o consultar frecuentemente, se puede imprimir con se¬ 
guridad o colocar en una intranet. Una abundancia de información que se debe transmitir a 
usuarios que se encuentran a grandes distancias en las subsidiarias de la empresa se podría 
distribuir mejor de forma electrónica, por medio de Web o extrañéis, y dejar que el destina¬ 
tario decida si personaliza e imprime la salida, o si la despliega o la almacena. 

A veces las regulaciones federales o estatales estipulan que un formulario impreso debe 
permanecer en una ubicación particular por un periodo específico. En esos casos, el analista 
de sistemas tiene la responsabilidad de ver que la regulación sea observada para cualquier 
salida nueva o modificada que se diseñe. 

¿Cuál es el propósito de la salida? El propósito de la salida es otro factor que se debe 
considerar al escoger la tecnología de salida. Si la salida tiene el propósito de ser es un infor¬ 
me creado para atraer a los accionistas al negocio permitiéndoles examinar las finanzas cor¬ 
porativas en su tiempo libre, es deseable contar con una salida impresa bien diseñada, tal co¬ 
mo un informe anual. También se podría usar una variedad de medios para que el informe 
anual esté disponible en Web así como también en forma impresa. Si el propósito de la sali¬ 
da es proporcionar actualizaciones de 15 minutos en las cotizaciones de la bolsa de valores. 
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y si el material es altamente codificable y cambiable, se prefieren las cintillas móviles en la 
pantalla, páginas Web o presentaciones de audio. 

¿Cuál es la velocidad con que se necesita la salida? Conforme avanzamos por los tres ni¬ 
veles de administración de la organización (la estratégica, la de nivel medio y la de operacio¬ 
nes) encontramos que los tomadores de decisiones en el nivel inferior de la administración de 
operaciones necesitan con urgencia la salida para responder con rapidez a los eventos, tal 
como una línea de ensamble detenida, materia prima que no ha llegado a tiempo o un obrero 
que se ausenta inesperadamente. En estos casos podría ser útil la salida de pantalla en línea. 

Conforme ascendemos en los niveles de la administración, observamos que los gerentes 
estratégicos tienen mayor necesidad de salida de un periodo específico, lo cual les ayuda a 
pronosticar ciclos y tendencias de negocios. 

¿Con qué frecuencia se accederá a la salida? Entre más frecuentemente se acceda a una 
salida, más importante es la capacidad de verla en una pantalla conectada a redes de área local 
o en Web. Las microformas, por otra parte, satisfacen la necesidad de salida que se accede 
con muy poca frecuencia y sólo por unos cuantos usuarios. 

La salida que se accede con mayor frecuencia es buena candidata para incorporarla en 
sistemas basados en Web y otros sistemas en línea o redes con pantallas. Adoptar este tipo 
de tecnología permite acceso fácil a los usuarios y alivia el desgaste físico que sufre frecuen¬ 
temente la salida impresa por el manejo. 

¿Cuánto tiempo se almacenará la salida? La salida impresa en papel se deteriora rápida¬ 
mente con el tiempo. La salida conservada en microformas o digitalizada no se deteriora 
,con los factores ambientales como la luz y la humedad o con el manejo humano. 

Un negocio podría estar sujeto a las regulaciones gubernamentales en niveles locales, esta¬ 
tales o federales, que determinen cuánto tiempo se debe almacenar la salida. Si la organización 
desea mantener archivada la información, y ésta no es confidencial, puede conservarla en su 
sitio Web en la forma de documentos Web. Las organizaciones mismas también establecen po¬ 
líticas acerca de cuánto tiempo se debe almacenar la salida. 

¿Bajo qué regulaciones especiales se produce, almacena y distribuye la salida? El forma¬ 
to adecuado para algunas salidas es regulado principalmente por el gobierno. Por ejemplo, se 
debe imprimir el formulario W-2 de un empleado; su formulario final no puede ser una 
salida de pantalla o de microforma. Cada negocio existe dentro de un complejo diferente 
de regulaciones bajo las cuales se produce la salida. Hasta ese grado, la tecnología apropiada 
para algunas funciones podría ser dictada por la ley. 

Sin embargo, mucha de esta regulación depende de la industria. Por ejemplo, la ley federal 
exige a un banco local de sangre conservar un historial médico de un donador de sangre —así 
como también su nombre— en el archivo. No se especifica la forma exacta de la salida, pero 
el contendido se explica rigurosamente. 

¿Cuáles son los costos iniciales y finales del mantenimiento y suministro? Los costos 
iniciales de comprar o arrendar equipo aún se deben considerar como otro factor que entra 
en la opción de tecnología de salida. La mayoría de los vendedores le ayudará a estimar 
los costos iniciales de la compra o del arriendo de hardware de computadora, incluyendo 
el costo de impresoras y pantallas, el costo de acceso a los proveedores de servicio en línea 
(acceso a Internet] o los costos de construir intranets y extranets. Sin embargo, muchos 
vendedores no proporcionan información acerca de cuánto cuesta mantener en funciona¬ 
miento una impresora u otras tecnologías. Por lo tanto, toca al analista investigar los cos¬ 
tos de operar tecnologías de salida diferentes o de mantener un sitio Web corporativo todo 
el tiempo. 
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E CONSULTORA 11,2 


UNA FORMA CORRECTA, UNA FORMA 
INCORRECTA Y UN METRO 


"Hasta aquí todo va bien. Es verdad, ha habido algunas quejas, pero 
cualquier nuevo metro las tendrá, El truco del 'viaje gratis 1 ha contribuido 
a atraer a algunas personas que de otra forma nunca hubieran viajado en 
él. Creo que hay más gente que nunca Interesada en viajar en el metro", 
dice Bart Rayl, "Lo que necesitamos es un arreglo preciso de la cantidad de 
gente que ha viajado hasta ahora para que podamos hacer algunos ajus¬ 
tes en nuestras decisiones de tarifas y fijación de horarios de trenes." 

Rayl es gerente de operaciones para S.W.I.F.T, el metro que recientemen¬ 
te se construyó para Western Ipswlch y Fremont Transport y que da servicio 
a una ciudad nororlental de Estados Unidos. Rayl está hablando con Benton 
Turstile, que le reporta a él corno supervisor de operaciones de S.W.I.F.T. El 
sistema del metro está en su primer mes de funcionamiento, con líneas 
limitadas. La gente de marketing ha estado regalando viajes en el metro 
con el propósito de que el público conozca mejora S.W.I.F.T. 

"Creo que ésa es una buena idea", dice Turnstile. "No es sólo un es¬ 
fuerzo en vano. Le mostraremos a la gente que realmente estamos en el 
camino correcto. Volveré pronto con Información sobre la cantidad de 
gente que viaja", dice. 

Un mes después, Rayl y Turnstile se reúnen para comparar la cantidad 
de viajeros proyectados con los nuevos datos. Turnstile presenta orgullo- 
sámente a Rayl una pila de documentos impresos en computadora de dos 
pulgadas de altura. Rayl parece un poco sorprendido pero en seguida em¬ 
pieza a revisarlos junto con Turnstile. "¿Qué tanto hay aquí?", pregunta 
Rayl, tamborileando los dedos en la primera página con vacilación. 

"Bueno", dice Turnstile, mientras pasea la vista por los documentos, "es 
una lista de todos los boletos que se vendieron de las máquinas computarl- 
zadas. Nos indica cuántos boletos fueron comprados y de qué tipo son. Los ti¬ 
pos de Systems That Think, Inc., me dijeron que este informe sería el más 
útil para nosotros, como lo fue para la gente de operaciones de Búfalo y Pitts- 
burgh", dice Turnstile, dando la vuelta rápidamente a la siguiente página. 

"Quizá, pero recuerda que aquellos sistemas del metro empezaron 
con un servicio muy limitado. Nosotros somos más grandes. ¿Y qué hay 
sobre las ventas de las tres casetas de boletos con operadores de la es¬ 
tación Main Street?", pregunta Rayl. 


"Los empleados de la caseta pueden obtener información resumida en 
pantalla sobre las ventas de boletos siempre que la necesiten, pero aquí no 
se incluye. Recuerda que proyectamos que sólo 10 por ciento de nuestras 
ventas provendrían de las casetas. Sigamos con nuestra idea original e in¬ 
corporemos esto en los documentos impresos", sugiere Turnstile. 

Rayl contesta: "Pero he estado observando a los pasajeros. La mitad 
de ellos parece tener miedo de las máquinas de boletos computarizadas. 
Otros que empiezan a usarlas, se frustran leyendo las Instrucciones, o no 
saben qué hacer con el boleto que reciben, y acaban frente a las casetas 
de boletos echando humo. Además, ellos no pueden entender la Informa¬ 
ción rutinaria anunciada en los kioscos, que se presenta en forma gráfica. 
Terminan por preguntar a los empleados qué tren va a qué parte". Rayl 
empuja a un lado de la mesa de conferencias los documentos que con¬ 
tienen las ventas de boletos y dice: "No le tengo mucha confianza a este 
Informe. Me siento como si estuviéramos aquí sentados Intentado operar 
el sistema de metro más sofisticado de Estados Unidos mirando fijamen¬ 
te un túnel en lugar de la información, como deberíamos estar haciéndolo. 
Creo que necesitamos pensar en serio sobre capturar la información de 
la jornada en tarjetas con cintas magnéticas como lo está está haciendo 
el Departamento de Tránsito de Nueva York. Cada vez que insertas la tar¬ 
jeta para viajar, se almacena la información". 

¿Cuáles son algunos de los problemas específicos con la salida que 
los consultores de sistemas y Benton Turnstile presentaron a Bart Rayl? 
Evalúe los medios que se están usando para la salida así como la oportu¬ 
nidad de su distribución. Dé su opinión sobre la salida externa que los 
usuarios de las máquinas de boletos computarizadas están recibiendo. 
Sugiera algunos cambios en la salida para ayudara Rayl a obtener la In¬ 
formación que necesita para tomar decisiones concernientes a las tarifas 
y horarios de trenes, y para ayudara los usuarios del sistema del metro a 
conseguir la información que necesitan. ¿Cuáles son algunas de las deci¬ 
siones que enfrenten las organizaciones como el Departamento de Tránsito 
de Nueva York si recolectan y guardan la entrada acerca de los destinos de 
un Individuo cada vez que hace un viaje? ¿Qué cambios tendría que hacer 
S.W.I.F.T. a su salida y sus boletos si adopta esta tecnología? 


¿Cuáles son los requerimientos ambientales (absorción del ruido, temperatura controlada, área 
para el equipo, cableado y proximidad a transmisores inalámbricos o puntos de acceso ("zo¬ 
nas activas")) para las tecnologías de salida? Las impresoras necesitan un entorno seco y fres¬ 
co para funcionar adecuadamente. Los monitores necesitan espacio para ser instalados y operar. 
La salida de audio y vídeo necesita un entorno tranquilo para poderse apreciar y no debe ser 
audible para los empleados (o clientes) que no la estén usando. De esta manera, el analista no 
debe especificar la salida de audio para una situación de trabajo en la cual muchos empleados 
están comprometidos en una variedad de tareas que no están relacionadas con la salida. 

Con el propósito de establecer redes inalámbricas de área local de manera que los usua¬ 
rios puedan acceder de manera inalámbrica a Web, se debe disponer de los puntos de acceso 
inalámbricos. Éstos funcionan cuando las PCs están dentro de un radio de unos cientos de 
metros de los transmisores, pero pueden estar sujetos a interferencia por otros dispositivos. 

Algunas tecnologías de salida se aprecian por su discreción. Las bibliotecas, las cuales dan 
énfasis al silencio en el lugar de trabajo, usan una gran cantidad de pantallas para los do¬ 
cumentos Web y para otra información de base de datos conectada a la red, pero las impre¬ 
soras podrían ser escasas. 
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CÓMO AFECTA A LOS USUARIOS EL SESGO DE LA SALIDA 

Sin importar la forma en que se presente, la salida no es tan sólo un producto neutro que es 
analizado y utilizado por los tomadores de decisiones. La salida afecta a los usuarios de mu¬ 
chas formas. La importancia de este hecho para el analista de sistemas es que se debe tener 
gran cuidado en el diseño de la salida para evitar un sesgo en las decisiones de los usuarios. 


RECONOCIMIENTO DEL SESGO EN LA FORMA EN QÜE SE USE LA SALIDA 

Un error común es asumir que ha acabado la influencia del analista de sistemas una vez que 
éste ha terminado un proyecto de sistemas. En realidad, la influencia del analista es muy du¬ 
radera. Mucha de la información en que los miembros organizacionales basan sus decisiones 
está determinada por lo que los analistas perciben como importante para el negocio. 

El sesgo está presente en todo lo que los humanos crean. Esta declaración no es para 
juzgar el sesgo como malo, sino para indicar que es inseparable de lo que nosotros [y por 
consiguiente nuestros sistemas) producimos. Los propósitos de los analistas de sistemas son 
evitar alterar sin necesidad la salida y hacer conscientes a los usuarios del posible sesgo en la 
salida que reciben. 

Las presentaciones de salida son involuntariamente sesgadas de tres formas principales: 

1. Cómo se clasifica la información. 

2. Establecer límites aceptables. 

3. Elección de gráficos. 

Cada fuente de sesgo se discute por separado en las subsecciones siguientes. 

Introducción de sesgo cuando se clasifica la información El sesgo se presenta en la salida 
cuando el analista elige cómo clasificar la información para un informe. Las clasificaciones 
comunes incluyen alfabéticas, cronológicas y de costo. 

La información presentada alfabéticamente podría dar demasiada importancia a los 
artículos que empiezan con las letras A y B, debido a que los usuarios tienden a prestar más 
atención a la información que se presenta primero. Por ejemplo, si los proveedores anterio¬ 
res se listan alfabéticamente, primero se muestran al gerente de compras compañías tales 
como Aardvark Printers, Advent Supplies y Barkley Office Equipment. Cuando ciertas 
aerolíneas crearon los sistemas de reservaciones SABRE y APOLLO, primero listaron sus 
propios vuelos, hasta que las otras aerolíneas se quejaron de que este tipo de clasificación 
era parcial. 

Introducción del sesgo al establecer límites Una segunda fuente principal de sesgo en la 
salida es una definición previa de límites para valores particulares a ser informados. Muchos 
informes se generan únicamente en una base de excepción, lo cual significa que cuando los 
límites en los valores se establecen de antemano, sólo se da salida a excepciones de esos 
valores. Los informes de excepción hacen al tomador de decisiones consciente de las desvia¬ 
ciones de los valores satisfactorios. 

Por ejemplo, los límites que se establecen demasiado bajo para los informes de excep¬ 
ción pueden alterar la percepción del usuario. Tal sería el caso de una compañía aseguradora 
que genera informes de excepción en todas las cuentas con una semana de retraso. En este 
caso, la empresa ha establecido un límite demasiado bajo en los pagos retrasados. El tomador 
de decisiones que recibe la salida se agobiará con las "excepciones" que realmente no son 
ninguna causa por la cual preocuparse. El informe de excepción con retraso de una semana 
induce al usuario a suponer que hay muchísimas cuentas retrasadas. Un límite más apropia¬ 
do para generar un informe de excepción podrían ser cuentas con 30 días o más de retraso. 

Introducción de sesgo a través de gráficos La salida está sujeta a un tercer tipo de sesgo 
de presentación que se provoca por la elección que el analista hace de gráficos para el 
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un gráñeo tendencioso 
probablemente alterará la 
percepción del usuario. 


Número de 
huéspedes 
que incum¬ 
plieron su 
reservación 



despliegue de la salida. El sesgo puede ocurrir en la selección del tamaño de gráfico, su co¬ 
lor, la escala usada e incluso el tipo de gráfico. 

El tamaño del gráfico debe ser proporcional para que el usuario no altere su percepción 
acerca de la importancia de las variables que se presentan. Por ejemplo, la figura 11.7 mues¬ 
tra un gráfico de columnas que compara el número de huéspedes que incumplieron reser¬ 
vaciones de hotel en 2002 con los huéspedes que lo hicieron en 2003. Observe que el eje 
vertical está roto y parece que el número de huéspedes que incumplieron reservaciones en 
2003 es el doble del número de los que incumplieron en 2002, aunque realmente el núme¬ 
ro sólo ha subido ligeramente. 


CÓMO EVITAR EL SESGO EN EL DISEÑO DE LA SALIDA 

Los analistas de sistemas pueden usar estrategias específicas para evitar el sesgo en la salida 
que diseñan: 

1. Esté consciente de las fuentes de sesgo. 

2. Haga un diseño interactivo de salida que incluya usuarios y una variedad de sistemas 
configurados de forma diferente durante la comprobación de la apariencia del docu¬ 
mento Web. 

3. Trabaje con los usuarios para que estén informados del sesgo de la salida y puedan 
reconocer las implicaciones de personalizar sus despliegues. 

4. Cree salidas que sean flexibles y que permitan a usuarios modificar límites y rangos. 

5. Capacite a los usuarios para apoyarse en salidas múltiples para obtener "segundas 
opiniones" de la salida del sistema. 

Todas estas estrategias (excepto la primera) se enfocan en la relación entre el analista de sis¬ 
temas y el usuario conforme este último se involucra en la salida. Los analistas de sistemas 
primero necesitan reconocer el impacto potencial de la salida y estar conscientes de las po¬ 
sibles formas en que la salida incluye involuntariamente un sesgo. 


DISEÑO DE SALIDA IMPRESA 

La fuente de información que se incluye en los informes es el diccionario de datos, cuyo 
proceso de recopilación se trató en el capítulo 8. Recuerde que el diccionario de datos in¬ 
cluye nombres de elementos de datos así como también el tamaño de campo requerido 
de cada entrada. 

Los informes entran en tres categorías: detallado, excepción y resumen. Los informes 
detallados imprimen una línea del informe para cada registro en el archivo maestro. Estos se 
usan para enviar por correo a clientes, enviar informes de calificación del estudiante, impri¬ 
mir catálogos, etc. Las pantallas de consulta han reemplazado muchos informes detallados. 

Los informes de excepción imprimen una línea para todos los registros que cumplen un 
conjunto de condiciones, tal como qué libros están retrasados en una biblioteca o qué estu- 


G333I 13 


ASPECTOS ESENCIALES DEL DISEÑO 





diantes están en el cuadro de honor. Normalmente éstos se usan para ayudar a gerentes ope- 
racionales y al personal de oficina para poner en funcionamiento un negocio. Los infor¬ 
mes de resumen imprimen una línea para un grupo de registros y se usan para tomar deci¬ 
siones, tal como qué artículos no se están vendiendo y cuáles sí. 



Un informé de salida impresa 
para los gerentes divisionales 
[ de un mayorista de comida. 


LINEAMIENTOS PARA DISEÑAR UN INFORME IMPRESO 

La figura 11.8 es un informe de salida destinado a gerentes divisionales de un mayorista de 
comida que abastece a varias tiendas de abarrotes franquiciatarias. Nos enfocaremos en 
diferentes aspectos del informe conforme cubrimos las herramientas, convenciones y los 
atributos funcionales y estilísticos del diseño de informes de salida impresos. 


Convenciones del diseño de un informe Las convenciones que se deben seguir al diseñar 
un formulario incluyen el tipo de dato [alfabético, especial o numérico) que aparecerá en 
cada posición, mostrar el tamaño del formulario a ser preparado y la forma de indicar una 
continuación de datos en formularios de diseño consecutivos. La mayor parte del software 
de diseño de formularios que usan actualmente los analistas incluye convenciones estándar 
para diseñar formularios en pantalla. Además, ofrece interfaces familiares del tipo "arrastrar 
y soltar" que le permiten seleccionar atributos, tal como un bloque de dirección con un clic 
del ratón y después soltarlo en la pantalla donde quiera colocarlo en su formulario. Estará 
usando WYSIWYG o "lo que ve es lo que obtiene", de tal manera que el diseño de formu¬ 
larios será un ejercicio sumamente visual. 

La información constante, o fija es información que permanece igual siempre que se im¬ 
prime el formulario. El título del informe y todos los encabezados de columna se escriben co¬ 
mo información constante. La información variable es información que puede cambiar cada 


DISEÑO DE UNA SALIDA EFICAZ 







PORTUNIDAD DE CONSULTO RIA 11.3 


SU TRABAJO ES PESADO? 


"A mí me gusta tener todo a la mano, y entre más fuerte se empaquete 
la Información, mejor. Olvídese de todo lo que oye hablar de la carga ex¬ 
cesiva de Información. Eso no existe en mi vocabulario. Yo la quiero toda, 
y no en un manojo de Informes bien adornados de media página. Yo la 
necesito toda junta, en una hoja que pueda llevar a una reunión por si 
necesito buscar algo. Y la necesito todas las semanas", afirma Stephen 
Llnks, vicepresidente de una gran compañía productora de salchichas, 
propiedad de su familia. 

Durante una entrevista, Links ha estado molestando a Paul Plishka, 
quien es parte del equipo de análisis de sistemas que diseña un sistema 
de información para Links Meats. Aunque Paul tiene dudas sobre lo que 
Links le ha dicho, procede a diseñar un informe Impreso que incluye to¬ 
dos los elementos Importantes que el equipo ha establecido durante la 
fase del análisis. 

Sin embargo, cuando le dan a Stephen un prototipo del nuevo infor¬ 
me, diseñado de acuerdo con sus especificaciones, parece que éste 
cambia de parecer. Links dice en forma ambigua que no puede encontrar 
lo que necesita. 


"Este material tiene una apariencia terrlble/Parece un libro de recor¬ 
tes. MI hijo de kínder hace mejores Informes con crayones. Míralo. Está 
todo apretado. No puedo encontrar nada. ¿Dónde está el resumen del nú¬ 
mero de piezas de carne de cerdo vendidas en cada tienda? ¿Dónde está 
el volumen total de piezas vendidas por todas las tiendas? ¿Qué hay sobre 
la información de nuestra propia tienda en esta ciudad?", dice Links, al 
tiempo que deja el informe, 

Evidentemente el informe necesita ser redlseñado. Diseñe un infor¬ 
me (o informes) que se adapte mejor a Stephen Links. ¿Qué rumbo puede 
seguir el analista para sugerir más informes con un formato menos 
apretado? Dé su opinión sobre la dificultad de ¡mplementar las suge¬ 
rencias del usuario que vayan en contra de lo que usted sabe sobre el 
diseño. ¿Cuáles son los pros y contras (en lo que respecta a la sobrecar¬ 
ga de información) de generar numerosos Informes enjugar de generar 
un Informe cuantioso que contenga toda la Información que necesita 
Stephen? Considere una solución basada en la Web que permita h¡- 
pervínculos a toda la Información que desea Stephen. ¿Qué tan factible 
es esta solución? 


vez que se imprime el informe. En nuestro ejemplo, las cifras de las ventas en miles de dó¬ 
lares cambiarán; por lo tanto, se indican como información variable. 

Calidad, tipo y tamaño del papel La salida se puede imprimir en innumerables tipos de pa¬ 
pel. La restricción principal normalmente es el costo. Un ejemplo es el uso de papel de seguri¬ 
dad para los cheques y sobres de cheques, así como también para documentos que deben 
llevar sellos oficiales e inalterables u hologramas, tal como los pasaportes. 

Los formularios preimpresos pueden comunicar fácilmente una imagen corporativa 
distintiva a través del uso de colores y diseños corporativos. El usar formas, colores y diseños 
innovadores también es una manera llamativa de atraer la atención de usuarios al informe 
contenido en el formulario preimpreso. 

Consideraciones de diseño En el diseño del informe impreso, el analista de sistemas reúne 
las consideraciones funcionales y estilísticas o estéticas para que el informe proporcione al 
usuario la información necesaria en un formato legible. Debido a que la función y la forma 
se refuerzan entre sí, a uno no se le debe dar énfasis a expensas del otro. 

Atributos funcionales. Los atributos funcionales de un informe impreso incluyen 
(1) el encabezado o título del informe; (2) el número de página; (3) la fecha de elabo¬ 
ración; (4) los títulos de columna; [5] la agrupación de elementos de datos relacionados 
entre sí, y (6) el uso de subtotales. Cada uno de éstos trata un propósito específico para 
el usuario. 

Hay varias consideraciones estilísticas o estéticas que debe observar el analista de siste¬ 
mas al diseñar un informe impreso. Si la salida impresa es desagradable y difícil de leer, no 
se usará eficazmente o tal vez ni siquiera se use. El peligro sería dar mala información a los 
tomadores de decisiones y desperdiciar los recursos organizacionales. 

Los informes impresos se deben organizar bien, reflejando la forma en que el ojo ve. 
En esta cultura, significa que el informe se debe leer de arriba abajo y de izquierda a de¬ 
recha. Como se mencionó anteriormente, los elementos de datos relacionados se deben 
agrupar. La estética del sitio Web y el diseño de páginas Web se tratan más adelante en este 
capítulo. 
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D (SE NO DÉ IÁSÁÜ D APA RÁIÑ FORMÉ SEN" A O N ÍTO RES 

En el capítulo 12 se trata el diseño de pantallas para la captura de datos, y aquí también se 
aplican los mismos lincamientos para diseñar la salida, aunque los contenidos cambiarán. 
Observe que la salida en pantalla difiere de varias formas de la salida impresa. Es efímera (es 
decir, la información en un monitor no es permanente del mismo modo que las impresio¬ 
nes], puede estar enfocada más específicamente al usuario, está disponible en un horario 
más flexible, no es portátil de la misma forma y algunas veces se puede cambiar a través de 
interacción directa. 

Además, a los usuarios se les debe enseñar cuáles teclas presionar cuando deseen conti¬ 
nuar leyendo pantallas adicionales, cuando deseen saber cómo acabar el informe y cuando 
deseen saber cómo interactuar con el monitor (si es posible). El acceso a las pantallas se po¬ 
dría controlar mediante el uso de una contraseña, mientras que la distribución de la salida 
impresa se controla por otros medios. 

LINEAMIENTOS PARA EL DISEÑO DE PANTALLAS 

Cuatro lineamientos facilitan el diseño de pantallas: 

1. Mantener el informe en pantalla simple. 

2. Ser consistente en la presentación. 

3. Facilitar el movimiento del usuario entre la salida desplegada. 

4. Crear un informe en pantalla atractivo. 

De igual forma que la salida impresa, los informes en pantalla buenos no se pueden crear de 
manera aislada. Los analistas de sistemas necesitan la retroalimentación de usuarios para 
diseñar informes importantes. Una vez aprobado por los usuarios, el diseño de los informes 
en pantalla se puede finalizar. 

En la figura 11.9 se describe la salida producida del diseño del informe en pantalla. Obser¬ 
ve que está ordenada y proporciona un resumen básico del estado del envío. El despliegue 
orienta a los usuarios acerca de lo que están observando con el uso de un título. Las instruccio¬ 
nes al fondo del informe proporcionan varias opciones a los usuarios, incluyendo continuar 
con el informe actual, terminar el informe, obtener ayuda o conseguir más detalle. 
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Estado de pedidos del Nuevo Zoológico 


Pedido # 

Fecha del pedido Estado ce! r-eádo 

933401 

09/05/2003 

Enviado en 09/29. 

934567 

09/11/2003 

Envjado en 0Ó r 

934613 

09/13/2003 

Envjado en 09^21 . 

934691 

09/14/2003 

Enviado en 09/21 

933603 

09/02/2003 

Parcialmente enviado 

933668 

09/08/2003 

Programado para 10/03 

934552 

09/18/2003 

Programado para 10/03 

934683 

09/18/2003 

Enviado en 09/28 

933414 

09/12/2003 

Enviado en 09/18 

933422 

09/14/2003 

Enviado en 09/21 

934339 

09/16/2003 

Enviado en 09/26 

934387 

09/18/2003 

Enviado en 09/21 

934476 

09/25/2003 

Nueva orden de pedido 

934341 

09/14/2003 

Enviado en 09/26 

934591 

09/18/2003 

Parcialmente enviado 

934633 

09/26/2003 

Nueva orden de pedido 

934664 

09/29/2003 

Parcialmente enviado 


Presione cualquier tecla para ver el resto de la lista: ESC para finalizar: ? para ayuda 
i mayor detalle coloque el cursor en el número de pedido y presione la tecla Enter. 
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Sí los usuarios quieren más 
detalles con respecto al estado 
del envío, pueden pedir una 
pantalla separada. 



La salida que se despliega en una aplicación debe mostrar la información de forma con¬ 
sistente de página en página. La figura 11.10 muestra el informe que resulta cuando el 
usuario posiciona el cursor sobre el número de pedido para un revendedor particular. El 
nuevo informe presenta más detalles sobre Bear Bizarre. En el cuerpo del informe, el usuario 
puede ver el número del pedido del revendedor, la dirección completa, la fecha del pedido y 
el estado. Además, se proporcionan un análisis detallado del envío y un estado detallado de 
cada parte del envío. Se proporcionan un nombre de contacto y un número telefónico, junto 
con el saldo de la cuenta, la solvencia y los antecedentes del envío. Observe que la parte in¬ 
ferior de la pantalla sugiere opciones al usuario, que incluye más detalles, cerrar el informe 
o buscar ayuda. 

En lugar de amontonar toda la información de los revendedores en una página, el ana¬ 
lista ha hecho posible que el usuario despliegue en otra pantalla la información relacionada 
con un revendedor particular si surge un problema o una pregunta. Por ejemplo, si el resu¬ 
men indica que un pedido únicamente fue enviado parcialmente, el usuario puede verificar 
el pedido más a fondo llamando un informe del revendedor detallado y después seguir ade¬ 
lante con la acción apropiada. 


USO DE LA SALIDA GRÁFICA EN EL DISEÑO DE PANTALLA 

La salida gráfica puede ser poderosa. Cuando se despliega el gráfico correcto es muy fácil 
identificar una tendencia o detectar un patrón. La mayoría de las personas observa con ma¬ 
yor facilidad las diferencias que hay en gráficos que las diferencias que hay en tablas. Es im¬ 
portante escoger el estilo correcto de gráfico para comunicar su significado. Usted podría 
necesitar repasar la sección de graficación del capítulo 10 para familiarizarse con las opciones. 

Al igual que la presentación de salida tabular, la salida gráfica necesita ser precisa y fá¬ 
cil de entender y usarse para comunicar de manera eficaz la información a los usuarios. Los 
tomadores de decisiones que usan gráficos necesitan saber las suposiciones bajo las cuales se 
construyen los gráficos (ya que éstos pudieran introducir un cierto nivel de sesgo) de manera 
que se puedan ajustar o compensar para ellos. 

En el diseño de la salida gráfica, el analista de sistemas debe determinar (1) el propósito 
del gráfico; (2) el tipo de datos que se necesita desplegar; (3] su público, y (4) los efectos en 
el público de diferentes tipos de salida gráfica. En el caso de un sistema de apoyo a la toma 
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Un gráfico de barras para 
desplegaren pantalla el 
tiempo de respuesta de las 
fuerzas de la policía. 


Tiempo de respuesta promedio según el área de cada tropa 
Policía del estado de Nebraska 


•Tiempo (en 
minutos) 25 


Actual ffl Pronosticado • Mínimo 


de decisiones, los propósitos de los despliegues gráficos son apoyar cualquiera de las tres 
fases de la resolución de problemas: inteligencia, diseño y selección. En la figura 11.11 
se muestra un ejemplo del sistema de DSS para la planeación de la distribución de efec¬ 
tivos de la patrulla del estado de Nebraska. Aquí se grafican los tiempos de respuesta 
actuales, los tiempos de respuesta pronosticados y los requerimientos mínimos con barras 
diferentes. 


DISEÑO DE UN SITIO WEB 

Cuando diseña un sitio Web, puede usar algunos de los principios del diseño de pantallas. 
Sin embargo, recuerde que aquí la palabra principal es sitio. A los primeros documentos 
mostrados en Internet mediante el protocolo http se les llamó páginas de inicio, pero pron¬ 
to quedó muy claro que las compañías, universidades, gobiernos y las personas no iban a 
desplegar una sola página. El término sitio Web reemplazó a página de inicio, el cual indica 
que la serie de páginas se debería organizar, coordinar, diseñar, desarrollar y mantener en un 
proceso ordenado. 

Imprimir es un medio altamente controlado, y el analista tiene una idea muy buena 
de cómo se verá la salida. La GUI y las pantallas basadas en caracteres alfanuméricos 
(CHUI, CHaracter-based User Interface o interfaz de usuario basada en caracteres) tam¬ 
bién están altamente controladas. Sin embargo. Web es un entorno con poco control sobre 
las salidas. 

Los diversos navegadores despliegan imágenes de forma diferente, y la resolución de 
pantalla tiene un gran impacto en el aspecto de un sitio Web. Las resoluciones estándar son 
1024 X 768 póceles o 1600 X 1200 pixeles. El problema es más complicado por el uso de 
dispositivos portátiles que se usan para navegar en Web. La complejidad aumenta cuando 
se comprende que cada persona podría ajustar su navegador para usar diferentes fuentes y 
podría desactivar el uso de JavaScript, cookies y otros elementos de programación en Web. 
Claramente, el analista debe tomar muchas decisiones al diseñar un sitio Web. 

Además de los elementos de diseño generales discutidos anteriormente en este capítulo, 
hay lincamientos específicos adecuados para el diseño de sitios Web de calidad profesional. 
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Término Web Significado 


"Marcador :iv Dirección almacenada-d| unapágína Wel/;(En Microsoft ínfernétí&Rlóre A ermarcadór-se A lama 
[bookrnark)7 V av6rJtc)s' A ) P A edé cambiar rápidamente una págira hacendó clic en este marcador, y 


Navegador Software que le permite leer páginas Web y copiarlas, guardarlas e imprimirlas. También le permite 
{browser) navegar en Web siguiendo los vínculos, yendo hacia atrás y hacia delante y cambiando rápidamente 

las páginas Web favoritas que ha marcado. Navegadores populares son Netscape Communicator 
y Microsoft Internet Explorer. 

FAQ Significa "Prei tas más frecuentes : Con frecuencia los sitios Web tienen una página dedicada 


mismas preguntas una y otra vez y los usuanos pueden tener 24 ñeras de acceso a las respuestas 

FTP El "Protocolo de Transferencia de Archivos" actualmente es la forma más común para mover archivos 

entre sistemas de cómputo. 

GIF Significa “F ato de intercambio de gráficos". Un formato popular de imagen comprimida más 

apropiado para las imágenes de línea. 

HTML El "Lenguaje de Marcado de Hipertexto" es el lenguaje detrás de la apariencia de documentos en Web. 

En realidad es un conjunto de convenciones que marcan las partes de un documento, que le informa 
a un navegador qué formato distintivo debe aparecer en cada parte de la página. 

http:// El "Protocolo de Transferencia de Hipertexto" se usa para mover páginas Web entre computadoras, 

tal como de un sitio Web alojado en una computadora en otro país a su computadora personal. 

Hipervínculo En un sistema de hipertexto, palabras, frases o imágenes que son delineadas o enfatizadas de alguna 
forma (con frecuencia con un color diferente). Cuando el usuario hace clic en uno de ellos, se desplie¬ 
ga otro documento. HTML tiene características que permiten a los autores insertar hipervínculos en sus 
documentos y los hipervínculos pueden apuntar hacia una página local u otro URL. Con frecuencia 
los vínculos cambiarán de color para Indicar que el usuario ya ha hecho clic en ellos anteriormente. 


Java. :Un|engüaje bríéntadoáóbjetosíjüe p”erm¡t6 A Scü1ar A icaciones dinámicas en Internet. 

;Los*norprogramadóres:pueden : :üsar paquetes de software tal como Symantec’s Visual Café para Java. 

JPEG El "Grupo de Expertos Fotográficos Unidos" desarrolló y dio el acrónimo de su nombre a este formato 

popular de imagen comprimida que es más apropiado para fotografías. El diseñador puede ajusfar la 
calidad de la imagen. 

plug-ins:—A":"’*..-Software!adicionai(éoTl A cuencia desarrollado por una tercera parte) que se puede usar con otro 
/ : ; "programa; pprejem plp\:RealNetworks':Real;Pjay.er o Macromedia Flash se usan como nlug-ins en 

: •» ~ los navegadores Webípárá :réj3ród'.üdrá'ute y vídeo de flujo continuo con calidad de G&f*;ver;í"<% 

•• v .” i *•> «r/im"6v,~t)"áa“ys("'is'</()í^”as visita la página Web. 

URL El "localizador uniforme de recursos" es la dirección de un documento o programa en Internet. Las 

extensiones familiares son .com para comercial, .edu para institución educativa, .gov para gobierno 
y .org para organización. 

VRML Él ""Lenguaje de Marcado deRealidad Virtual"es; un lengúájesímilarl HTML queipermíte a usuarios 

navegar en. tres dimensiones. V 

Webmaster Persona responsable del mantenimiento del sitio Web. 

www ••• Sign¡fica'"World WideWeb'Vün sistema dé 'hipértexto glóbáf que usé Internet. Ahora tan sólo nos 

referiremos a él como Web. ; " •' 





Términos del vocabulario de Web. 


En la figura 11.12 se definen los términos Web. Las siguientes subsecciones discuten estos 
lincamientos. 


LIGAMIENTOS GENERALES PARA DISEÑAR SITIOS WEB 

Hay muchas herramientas así como también ejemplos que pueden guiarlo en el diseño de 
sitios Web. 
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Casa diseñadora Dirección Web Sitios que diseñó 

Archetype www.archetypedesignco.ukwww.ctdu.org.uk ■ . • ! 

Organic www.organic.comwww.avis.com 


: www.macys.com 

www.unibanco.com 

. Modem moaia modemmedia.com , www.att.com traveler ’ 

y' .:'; r ; :Zfi . ;. • www.kraftfoods.com' : ¡ v 

■ yi; y:V. ;• /•• ¿.• ■■ T‘Yií 2;=í-A?; : 'f www.artmuseum.net 


Algunas casas diseñadoras de 
sitios WebCA/iA'} ;. ; : í 


Use herramientas profesionales Use software llamado editor Web tal como Macromedia 
Dreamweaver o Microsoft FrontPage. Definitivamente el precio de estas herramientas vale 
la pena. Será más creativo y terminará el sitio Web más rápido que si trabajara directamen¬ 
te con HTML (lenguaje de marcado de hipertexto). 

Estudie otros sitios Web Observe sitos Web que considere atractivos. Analice qué elementos 
de diseño se están usando y vea cómo funcionan, después intente emular lo que ve mediante 
la creación de páginas prototipo. (Cortar y pegar fotos o código no es ético o legal, pero sí se 
puede aprender de otros sitios.} 

Use los recursos que Web ofrece Observe sitios Web que proporcionan sugerencias para 
el diseño. Un sitio tal es useit.com. 

Examine los sitios Web de diseñadores profesionales En la figura 11.13 se mencionan al¬ 
gunas casas de diseño, junto con algunos de los sitios Web que desarrollaron y que son vi¬ 
sitados y elogiados con frecuencia. Conforme observe estas páginas, pregúntese: "¿Qué 
funciona? ¿Qué no funciona? ¿Cómo pueden interactuar los usuarios con el sitio? Por 
ejemplo, ¿el sitio tiene hiperenlaces para enviar correo a ciertas direcciones, formularios in¬ 
teractivos para llenar, encuestas para el cliente, juegos, exámenes, salones de conversación, 
etcétera?" 

Use las herramientas que ha aprendido La figura 11.14 proporciona un formulario que 
los diseñadores Web han usado con éxito para evaluar sistemáticamente las páginas Web. 
Podría querer usar copias del formulario para ayudarle a comparar y contrastar los sitios 
Web que visitará conforme aprenda el diseño de páginas Web. 

Consulte libros Algo que puede agregar a su experiencia en este nuevo campo es leer so¬ 
bre el diseño Web. Algunos libros de diseño de sitios Web son: 

Flanders, V. y D. Peters, Son ofWeb Pages That Suck: Learn Good Design by Looking at 
Bad Design, Alameda, CA: Sybex, 2002. 

Horton, W. K. y cois., The Web-Page Design Cookbook: AH the Ingredients Yon Need to 
Créate 5-StarWeb Pages, Nueva York: JohnWiley, 1996. 

Pring, R., www.type: Effective Typographic Design for the World Wide Web, Nueva York: 
Watson-Guptill, 2000. 

Weinman, L., Designing Web Graphics 4: How to Prepare Images and Media for the Web, 
4a. ed., Indianápolis, IN: NRP, 2002. 

Revise algunos ejemplos pobres de páginas Web Repase las páginas Web pobres y recuer¬ 
de evitar esos errores. Examine el sitio Web encontrado en www.webpagesthatsuck.com. A 
pesar de su nombre contracultural, éste es un sitio maravilloso que proporciona vínculos a 
muchos sitios diseñados pobremente e indica los errores que los diseñadores han cometido. 
Sin embargo, el sitio también proporciona vínculos al material que lleva al lector a través del 
proceso de creación de un sitio Web, mejorando la navegación del sitio, aprendiendo Java- 
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Un formulario de evaluación 
de sitios Web. 



Script y mucho más. Los autores son divertidos y están alertas para identificar los sitios Web 
buenos y malos, y proporcionan abundante información útil. 

Elabore sus propias plantillas Si usa una apariencia estándar de página para la mayoría de 
las páginas que desarrolla, tendrá su sitio Web instalado y funcionando rápidamente, con un 
aspecto agradable y consistente. Los sitios Web se podrían desarrollar mediante hojas de es¬ 
tilo en cascada que permiten al diseñador especificar una sola vez el color, tamaño de fuen¬ 
te, tipo de fuente y otros muchos atributos. Estos atributos se almacenan en un archivo de 
hoja de estilo y después se aplican a muchas páginas Web. Si un diseñador cambia una espe¬ 
cificación en el archivo de hoja de estilo, todas las páginas Web que usan dicha hoja de esti¬ 
lo se actualizarán para reflejar el nuevo estilo. 

Use plug-ins, audio y vídeo con moderación Es maravilloso tener las características con 
que cuentan las páginas profesionales, pero recuerde que no todos los que observan su sitio 
tienen cada plug-in nuevo. No desaliente a los visitantes a su página. 


Diseñe con anticipación Los sitios Web buenos son bien planeados. Ponga atención a lo si¬ 
guiente: 

1. Estructura. 

2. Contenido. 

3. Texto. 

4. Gráficos. 

5. Estilo de presentación. 

6. Navegación. 

7. Promoción. 

Cada uno de estos elementos se describe con más detalle a continuación. 

Estructura. Diseñar la estructura de un sitio Web es uno de los pasos más importantes 
en el desarrollo de un sitio Web profesional. Piense en sus metas y objetivos. Cada página en 
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la estructura Web global debe tener un mensaje distinto u otra información relacionada. A 
veces es útil examinar sitios profesionales para analizar su contenido y características. La 
figura 11.15 es una captura de pantalla del sitio Web techtv. El propósito para el sitio y el 
medio Web trabajan excepcionalmente bien en conjunto. En este sitio excelente, observe 
que hay gran atención a los detalles. Hay palabras, gráficos, imágenes JPEG e iconos. Además, 
hay muchos tipos de vínculos: por radio, vídeo, correo de voz, subWebs, salones de conversa¬ 
ción, motor de búsqueda y muchas otras características. JavaScript se usa para reproducir 
los encabezados y los clips de vídeo. 

Para poder diseñar y mantener una estructura sólida, un administrador Web se puede 
beneficiar del uso de una de las muchas herramientas de diagramación y mapeo de sitios 
Web disponibles. Muchos paquetes de software,-como Microsoft Visio, tienen opciones de 
mapeo en Web integradas. Aunque son útiles para el desarrollo, estas herramientas se vuel¬ 
ven aún más importantes en el mantenimiento de un sitio Web. Dada la naturaleza dinámi¬ 
ca de Web, los sitios que se vinculan a su sitio se podrían mover en cualquier momento, es¬ 
to requiere que usted, o su Webmaster, actualicen esos vínculos. 

En la figura 11.16 se muestra un mapa de una sección del sitio Web de los autores en 
una ventana de Visio. En este ejemplo, exploramos el sitio Web en todos los niveles existen¬ 
tes. Ahí se muestran los vínculos a las páginas HTML, documentos, imágenes (archivos GIF 
o JPEG] y "enviar correo a" (una forma de enviar el correo electrónico a una persona desig¬ 
nada] . Los vínculos pueden ser internos o externos. Si un vínculo se rompe, aparece una X 
en rojo y el analista puede investigar más a fondo. Este archivo de Visio se puede imprimir 
en secciones y se puede poner en una pared para obtener una apreciación global del sitio 
Web. 
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Un buen libro que trata la estructura del sitio Web es Lcirge-Scale Web Sites, de Darrell 
Sano, publicado en 1996 por John Wiley & Sons. 

Contenido. El contenido es crítico. Sin nada que decir, su sito Web fallará. Un amigo 
nuestro de 12 años, muy inteligente para su edad, nos confesó: "Podría hacer mi propio si¬ 
tio Web, ¿pero cuál es el propósito? ¡No tengo nada que decir!" La animación emocionante, 
películas y sonidos son divertidos, pero debe incluir contenido adecuado para mantener 
interesado al lector. 

Proporcione algo importante a los visitantes del sitio Web. Proporcione algunas suge¬ 
rencias oportunas, información importante, una oferta o cualquier actividad que pueda 
proporcionar que sea interactiva y mueva a los usuarios de un modo de navegación a uno 
interactivo. 

La "pegajosidad" es una cualidad que puede poseer un sitio Web. Si un usuario perma¬ 
nece en su sitio por un periodo prolongado, su sitio tiene un alto grado de pegajosidad. Por 
eso un comerciante incluye muchos artículos de interés en un sitio. Por ejemplo, un comer¬ 
ciante de vino podría poner instrucciones de cómo descorchar una botella, catar el vino o 
escoger una copa adecuada. 

Use una metáfora o imágenes que proporcionen una metáfora para su sitio. Puede usar 
un tema, como una vitrina, y que las páginas adicionales tengan varias metáforas relaciona¬ 
das con la vitrina, tal como una tienda de embutidos. Evite el uso excesivo de dibujos anima¬ 
dos y no sea repetitivo. Un ejemplo del uso de metáforas se puede encontrar en el sitio Web 
www.javaranch.com, el cual se usa como un recurso para aquellos que aprenden y usan el 
lenguaje de programación Java. Consulte la figura 11.17. Observe en todas partes el uso de 
términos de rancho. El Big Moose Saloon es un área de discusión, el Cattle Drive da una 
experiencia actual de escritura del código de Java, etcétera. 

Cada sitio Web debe incluir una página FAQ. Al tener las respuestas disponibles las 24 
horas del día, ahorrará tiempo valioso del empleado y también del usuario. Las páginas FAQ 
también demuestran a los usuarios de su sitio que usted está de acuerdo con ellos y tiene 
una buena idea de lo que les gustaría saber. 

En Web, el software COTS tiene otro significado. Un sitio Web podría tomar ventaja 
del software preescrito. Los ejemplos incluyen motores de búsqueda (tal como Googlej, 
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software de mapeo (tal como MapQuest], información del clima y marquesinas de noticias 
y de la bolsa de valores. Los diseñadores de sitio Web valoran estos paquetes porque pueden 
aumentar la funcionalidad del sitio y las características adicionales alientan a los usuarios a 
marcar sus sitios Web porque proporcionan el contenido esperado y dan un valioso bono 
adicional. 

Texto. No olvide que también el texto es importante. Cada página Web debe tener un 
título. Coloque palabras significativas en la primera frase que aparece en su página Web. Haga 
saber a las personas que han navegado al sitio Web correcto. La escritura clara es especial¬ 
mente importante. 

Gráficos. La siguiente lista proporciona detalles sobre la creación de gráficos eficaces 
para los sitios Web. 

1. Use uno de los dos formatos de imagen más comúnmente usados, JPEG o GIF. Los 
JPEGs son mejores para las fotografías, y los GIFs son mejores para las imágenes gráfi¬ 
cas o de línea. Los GIFs se limitan a 256 colores pero podrían incluir un fondo transpa¬ 
rente, pixeles que permiten que el fondo se muestre a través de la imagen GIF. Éstas 
también se podrían entrelazar, significa que el navegador Web mostrará la imagen en fa¬ 
ses sucesivas, presentando una imagen más clara con cada fase. 

2. Mantenga el fondo simple y asegúrese que los usuarios puedan leer claramente el 
texto. Al usar un patrón como fondo, asegúrese que puede ver claramente el texto 
sobre él. 

3. Desarrolle unos cuantos gráficos de apariencia profesional para usarlos en sus páginas. 

4. Mantenga las imágenes gráficas pequeñas y reúse marcas y botones de navegación tales 
como ATRÁS, ARRIBA, CORREO ELECTRÓNICO y ADELANTE. Estas imágenes se 
almacenan en caché, una área en la unidad de disco duro de la computadora de navega¬ 
ción. Una vez que se ha recibido una imagen, se tomará del caché siempre que se use de 
nuevo. Usar las imágenes del caché mejora la velocidad con que un navegador puede car¬ 
gar una página Web. 

5. Examine su sitio Web en una variedad de monitores y resoluciones de pantalla. Las 
escenas y el texto que tienen buena apariencia en un monitor de vídeo de alta calidad 
podrían no tener el mismo aspecto para otros que usan equipo de baja calidad. 
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Estilo de presentación. La siguiente lista proporciona detalles adicionales sobre cómo 
diseñar pantallas de entrada atractivas para los sitios Web. 

1. Proporcione una pantalla de entrada (también llamada página de inicio] que introdu¬ 
ce al visitante al sitio Web. La página se debe diseñar para cargar rápidamente. Una 
regla general útil es diseñar una página que cargará en 14 segundos, suponiendo que 
un usuario tiene un módem de 56K. (Aunque podría diseñar la página en una estación 
de trabajo en la universidad, un visitante de su sitio Web podría tener acceso desde su 
casa.} Esta pantalla de entrada debe ser de 100 kilobytes o menos, incluyendo todos 
los gráficos. 

La página de inicio debe contener varias opciones, parecido a un menú. Una forma 
fácil de lograrlo es diseñar un grupo de botones y posicionarlos en el lado izquierdo o 
en la parte superior de la pantalla. Estos botones se pueden vincular a otras páginas en 
el mismo sitio Web o a diferentes sitios Web. En la parte superior o inferior de la pági¬ 
na se podría incluir un menú de texto en fuente más pequeña. En la figura 11.18 se 
muestra un ejemplo de esto, una página de inicio que contiene una imagen grande y al¬ 
go de contenido, pero después orienta al visitante para navegar en otra parte del sitio. 
Esta página se construyó con software que permite a diseñadores ver código HTML 
(en la parte inferior de la pantalla] al mismo tiempo que ven cómo luciría la página en 
un navegador. 

2. Mantenga el número de gráficos a un mínimo razonable. Toma más tiempo descargar 
un sitio muy cargado de gráficos. 

3. Para los títulos use fuentes grandes y con color. 

4. Use imágenes y botones interesantes para los vínculos. A un grupo de imágenes combi¬ 
nado en una sola imagen se le llama mapa de imagen, el cual contiene varias zonas 
activas que actúan como vínculos a otras páginas. 

5. Use tablas para mejorar un diseño. Son fáciles de usar. 

6. Use la misma imagen gráfica en varias páginas Web. La consistencia se mejorará y las 
páginas se cargarán más rápidamente porque la computadora almacena la imagen en 
un caché y no debe cargarla nuevamente. 

7. Evite el uso excesivo de animación, sonido y otros elementos. 





Al usar un editor visual HTML 
(en este ejemplo, Visual Page), 
un diseñador de sitio Web puede 
ver cómo luce una página en 
un navegador y en código 
HTML (ver la parte inferior de 
la pantalla) al mismo tiempo. 
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Navegación. ¿Para usted es divertido seguir los vínculos en Web? La respuesta más 
común es: depende. Cuando descubre un sitio Web que se carga fácilmente, tiene vínculos sig¬ 
nificativos y le permite volver con facilidad a los lugares que desee, entonces piensa que es 
divertido. La diversión no es sólo jugar; también puede ser una parte importante del traba¬ 
jo. Las investigaciones recientes muestran que la diversión puede tener un efecto poderoso 
en la capacitación por computadora. 

Si por otro lado, no puede decidir qué botón o zona activa oprimir, y tiene miedo de 
escoger el equivocado porque podría entrar en una página errónea que requiere mucho 
tiempo para cargar, la navegación es más dolorosa que divertida. Un ejemplo es visitar 
la página de una compañía de software para encontrar información acerca de las carac¬ 
terísticas de la última versión de un producto. Tiene opciones tales como productos, 
descargas, FAQ y soporte técnico. ¿Qué botón le conducirá a las respuestas que está 
buscando? 

Lo más importante, observe la regla de los tres clics. Un usuario debe poder desplazarse 
de la página en que actualmente está a la página que contiene la información que necesita 
en solo tres clics del ratón. 

Promoción. Promueva su sitio. No asuma que los motores de búsqueda lo encontrarán 
en seguida. Envíe su sitio a varios motores de búsqueda de vez en cuando. Incluya palabras 
clave, llamadas metaetiquetas, que los motores de búsqueda usarán para vincular peticiones de 
búsqueda a su sitio. También puede comprar el software para hacer este proceso más fácil. 
Si intenta usar el correo electrónico para promover su sitio, otros lo considerarán correo 
electrónico chatarra o de basura. 

Anime a sus lectores a marcar su sitio Web. Si está vinculado y sugiere que vayan a 
sitios Web afiliados que ofrecen la "mejor página de revisión de película en el mundo" o 
al sitio Web donde "consiguen la música gratuita", no asuma que regresarán a su sitio en 
un futuro cercano. Los animará a que visiten nuevamente su sitio si es que lo marcaron 
(en Microsoft Internet Explorer los marcadores se llaman "favoritos"]. También podría 
diseñar un "favicon", o icono favorito, para que los usuarios puedan identificar su sitio en 
sus listas de favoritos. 


PRODUCCIÓN DE LA SALIDA Y XML 


La producción de la salida varia, dependiendo de la plataforma usada para producirla. Hay 
muchas maneras diferentes de crear la salida, que van desde el software simple de base de 
datos, como Microsoft Access, hasta los programas como SAS, Crystal Reports y los archi¬ 
vos PDF de Adobe Acrobat. 

Nosotros discutimos XML en el capítulo 8. Una de las ventajas de usar XML es que el 
documento de XML puede transformarse en diferentes medios de salida. Esto se logra 
usando hojas de estilo en cascada [CSSs] o transformaciones del lenguaje extensible de 
hojas de estilo (XSLTs). Estos métodos refuerzan la idea que deben definirse los datos una 
vez y deben usarse muchas veces en los diferentes formatos. 

Las hojas de estilo en cascada son una manera fácil de transformar un documento de 
XML. La hoja de estilo proporciona una serie de estilos, como el tipo de fuente, el tamaño, 
el color, el borde, y así sucesivamente, que se unen a los elementos del documento de 
XML. Estos estilos pueden variar para los medios de comunicación diferentes, como una 
pantalla, salida impresa o un dispositivo portátil. El software transformador detecta el tipo 
de dispositivo y aplica los estilos correctos para controlar la salida. 

Por ejemplo, un estilo usado para una pantalla plana podría usar una paleta rica de co¬ 
lores y una fuente tipo sans serif que son más fácil de seguir al leer una pantalla. Un estilo 
diferente que usa una fuente tipo serif y colores negro o gris se puede usar para definir un 
informe impreso para los mismos datos. Un tamaño de fuente más pequeño podría usarse 
para un dispositivo portátil, como una computadora Palm. 
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DIA DE CAMPO 


"El punto es que ya me impacienté", dice Seymour Fíelds, dueño ele 
Flelds, una cadena de 15 florerías muy exitosas en mercados florales 
de tres ciudades del medio oeste. "¿Ve esta cosa?" Golpea con molestia 
la pantalla de su PC. "Nosotros hacemos toda la nómina y toda la contabi¬ 
lidad con estas cosas, pero yo no la uso como debiera. Me siento un poco 
culpable realmente sobre esto. ¿Ve?" dice, mientras pasa un dedo sobre 
la pantalla. "Incluso tiene polvo. Sin embargo, soy una persona práctica. 
SI la tengo aquí, ocupando espacio, tengo que usarla. U olería, o por lo 
menos difrutar mirándola, o podarla, como las flores, ¿no es así?, eso es 
lo que yo digo. La única que vez que intenté hacer algo con ella, fue un 
verdadero desastre. Bien, mira, te mostraré si recuerdo cómo hacerlo." 
Seymour procede a tratar de iniciar un programa, pero al parecer no lo 
consigue. 

Clay Potts, un analista de sistemas, ha estado trabajando en un 
proyecto de sistemas para toda la cadena Fields. Parte de la propuesta 
original era proporcionar a Seymour y a sus vicepresidentes un sistema 
de apoyo a la toma de decisiones que les ayudaría a concebir una estra¬ 
tegia para determinar qué mercados europeos visitar para comprar flores 
frescas, a cuáles tiendas enviar tipos específicos de flores, y cuánta 


mercancía general, como macetas, jarrones, tarjetas de notas y adornos, 
para abastecer a cada tienda. 

Seymour continúa: "Te puedo decir loque detestamos sobre el pro¬ 
grama con que yo trabajé. Había demasiadas capas, demasiado follaje, 
o como lo llames, que había que brincar. Incluso con una pantalla frente 
a mí, era como hojear un informe muy grueso. ¿Cómo le llamas a eso?" 

"¿Menús?”, sugiere Potts de manera atingente. "El punto principal 
es que no le gustó tener que pasar por mucha Información para conse¬ 
guir la pantalla que necesitaba." 

Seymour Flelds mira a Potts alegremente y dice: "Ya me entendiste. 
Quiero ver más campos en cada pantalla". 

¿Cómo debe diseñar Potts la salida en pantalla para que Flelds y su gru¬ 
po puedan obtener lo que quieren en cada pantalla siguiendo al mismo 
tiempo los lineamientos para realizar un buen diseño de pantallas? Recuer¬ 
de que los miembros del grupo están ocupados y que por lo general no son 
usuarios frecuentes de computadoras. Diseñe una página con hlpervínculos 
que funcione bien en un DSS para los vicepresidentes. ¿Qué debe Incluirse 
en la primera pantalla, y que se debe almacenar en los hlpervínculos? Liste 
elementos para cada uno y explique por qué se Inclinó por esta estrategia. 


La desventaja de las hojas de estilo en cascada es que no le permiten al analista mani¬ 
pular los datos, como reestructurar el orden de los elementos u ordenar, y sólo permiten agre¬ 
gar una cantidad limitada de texto identificador, como los subtítulos. 

Las transformaciones del lenguaje extensible de hojas de estilo (XSLTs) son un medio 
más poderoso de transformar un documento de XML. Ellas le permiten al analista seleccio¬ 
nar los elementos e insertarlos en una página Web u otro medio de salida. La figura 11.19 
ilustra el proceso de la transformación. XSLT no es un lenguaje de programación, pero usa 
una serie de declaraciones para definir qué elementos deben ser salida, la forma de ordenar, 
la selección de datos, y así sucesivamente. 




; El software de transformación del 
lenguaje extensible de hojas 
de estilo (XSLT) se puede usar 
para hacer documentos XML 
y transformarlos en muchos 
}' formatos diferentes para una 
variedad de plataformas. 
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RESUMEN 


La salida es cualquier información útil o los datos entregados al usario por el sistema de in¬ 
formación o por el sistema de apoyo a la toma de decisiones. La salida puede tomar casi 
cualquier forma, incluyendo impresión, mostrar en un monitor, audio, microformas, CD- 
ROMs o DVDs y los documentos basados en Web. 

El analista de sistemas tiene seis objetivos principales en el diseño de la salida. Ellos 
deben diseñar la salida para servir el propósito para el que fue creada, satisfacer al usuario, 
entregar la cantidad correcta de salida, entregarla al lugar correcto, proporcionar la salida a 
tiempo y escoger el método de salida correcto. 

Es importante que el analista comprenda que el contenido de la salida se relaciona con 
el método de salida. La salida de tecnologías diferentes afecta a los usuarios de distintas 
formas. Las tecnologías de salida también difieren en su velocidad, costo, portabilidad, flexi¬ 
bilidad y posibilidades de almacenamiento y recuperación. Todos estos factores se deben 
considerar al decidir entre la impresión, mostrar en un monitor, salida de audio, electrónica 
o basada en Web, o una combinación de éstos. 

La presentación de salida puede alterar la percepción de los usuarios en su interpreta¬ 
ción de ésta. Los analistas deben estar conscientes de las fuentes de sesgo, deben interactuar 
con los usuarios para diseñar y personalizar la salida, deben informar a los usuarios de las 
posibilidades de sesgo en la salida, deben crear salidas flexibles y modificables, y deben 
capacitar a los usuarios para usar salidas múltiples para poder verificar la exactitud de cual¬ 
quier informe particular. 

Los informes impresos se diseñan con el uso de herramientas de diseño de software asisti¬ 
do por computadora que ofrecen plantillas de diseño de formulario y las interfaces de arrastrar 
y soltar. El diccionario de datos sirve como fuente para los datos necesarios en cada informe. 

El diseño de salida para las pantallas es importante, sobre todo para los sistemas de apoyo 
a la toma de decisiones, así como también para Web. Una vez más, la estética y utilidad son 
importantes al crear salida bien diseñada para los despliegues. Es importante producir proto¬ 
tipos de pantallas y documentos Web que permiten a usuarios hacer cambios donde deseen. 

PALABRAS Y FRASES CLAVE 

boletín electrónico 
CD-ROM 

correo electrónico 
diseño de la salida 
DVD 

favoritos 
hipertexto 
hipervínculo 

hoja de estilo en cascada (CSS) 
información constante 
información variable 
Java 

localizador uniforme de recursos (URL) 
navegador 
página Web 


pantalla de despliegue 

pegajosidad 

plug-in 

preguntas frecuentes 
salida de audio 
salida electrónica 
salida externa 
salida interna 
sesgo de la salida 
sitio Web 

transformaciones del lenguaje 

extensible de hojas de estilo (XSLT) 
Webmaster 

World Wide Web (WWW) 


PREGUNTAS DE REPASO 

1. Mencione seis objetivos que persigue el analista al diseñarla salida del sistema. 

2. Compare las salidas externas con las salidas internas que produce el sistema. 

3. ¿Cuáles son las tres situaciones que indican que las impresoras son la mejor elección 
para la tecnología de salida? 
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EXPERIENCIA CON HYPERCASE® 


'Yo diría que la recepción que usted recibió, o debo decir que su equipo recibió, acerca de 
la presentación de su propuesta fue bastante calurosa. ¿Qué le pareció haber conocido al 
señor Hyatt? ¿Qué? ¿Él no asistió? Oh [riéndose], él tiene su personalidad. Sin embargo, no 
se preocupe demasiado. Los informes que recibí de Snowden fueron favorables. De hecho, 
ahora él quiere ver algunos diseños preliminares de ustedes. ¿Puede mandarle algo a su 
escritorio o a su computadora dentro de dos semanas? Él estará en Singapur en viaje de 
negocios la próxima semana, pero cuando se recupere del viaje, él podrá ver esos diseños. 
Gracias." 



PREGUNTAS DE HYPERCASE 

1. Considere los informes de la Unidad de Capacitación. ¿Cuáles son las quejas de Snowden 
sobre estos informes? Explique en un párrafo. 

2. Usando un formulario en papel o una herramienta CASE, diseñe un prototipo de salida 
de pantalla con base en los informes de la Unidad de Capacitación que resumirán la si¬ 
guiente información para Snowden: 

El número de proyectos aceptados en la Unidad de Capacitación. 

El número de proyectos que se reevalúan actualmente. 

Las áreas de capacitación que requieren un consultor. 

3. Diseñe una pantalla de salida adicional que usted crea que apoyará a Snowden en el tipo 
de decisiones que él toma con frecuencia. 

4. Muestre sus diseños a tres compañeros de clase. Pídales retroalimentación en forma 
escrita para mejorar las pantallas de salida que diseñó usted. 

5. Rediseñe las pantallas para capturar las mejoras sugeridas por sus compañeros de clase. 
En un párrafo, explique cómo ha resuelto estas sugerencias. 
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En HyperCase tiene la posibilidad de ver y criticar las pantallas de salida. 
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4. Proporcione dos ejemplos que indiquen que las pantallas de salida son la mejor solución 
para la elección de tecnología de salida. 

5. Mencione los métodos potenciales de la salida electrónica. 

6. ¿Cuáles son las desventajas de la salida electrónica y la basada en Web? 

7. Mencione 10 factores que se deben considerar al escoger la tecnología de salida. 

8. ¿Qué tipo de salida es mejor si las actualizaciones frecuentes son una necesidad? 

9. ¿Qué tipo de salida es la adecuada si muchos lectores la leerán, almacenarán y revisarán 
durante un periodo de años? 

10. ¿Cuáles son dos de las desventajas de la salida de audio? 

11. Mencione tres formas principales en que las presentaciones de salida son involuntaria¬ 
mente desviadas. 

12. ¿Cuáles son las cinco formas en que el analista puede evitar la desviación de salida? 

13. ¿Cuál es la diferencia entre la información fija y la variable presentadas en un informe? 

14. ¿Por qué es importante mostrar a los usuarios un prototipo o pantalla de un informe de 
salida? 

15. Mencione seis elementos funcionales de los informes impresos. 

16. Mencione cinco elementos estilísticos o estéticos de los informes impresos. 

17. ¿De qué formas difieren las pantallas, la salida impresa y los documentos basados 
en Web? 

18. Mencione cuatro lincamientos para facilitar el diseño de una buena pantalla de 
salida. 

19. ¿Qué diferencia hay entre la salida para un DSS y la de un MIS más tradicional? 

20. ¿Cuáles son las cuatro consideraciones principales que el analista tiene al diseñar la 
salida gráfica para los sistemas de apoyo a la toma de decisiones? 

21. Defina pegajosidad. 

22. Mencione siete lincamientos para crear buenos sitios Web. 

23. Mencione cinco lincamientos para usar gráficos en el diseño de sitios Web. 

24. Mencione siete ideas para mejorar la presentación de sitios Web corporativos que usted 
diseña. 

25. ¿Cuál es la regla de los tres clics? 

26. ¿De qué formas puede recomendar a las empresas el promover los sitios Web que usted 
ha desarrollado? 

27. ¿De qué forma permite una hoja de estilo en cascada al analista producir la salida? 

28. ¿Cuáles son las ventajas de usar XSLT en lugar de una hoja de estilo en cascada? 

PROBLEMAS 

1. "Estoy seguro que no les importará si les enviamos el informe en estas hojas de compu¬ 
tadora demasiado grandes. Todo este tiempo lo hemos estado condensando, rescri¬ 
biendo y enviándolo a nuestras cuentas más grandes, pero ya no podemos. Estamos 
tan escasos de personal, no tenemos el tiempo", dice Otto Breth. "Tan sólo escribiré 
un comentario aquí diciéndoles cómo responder a este informe y después podemos 
mandarlo." 

a. ¿Qué problemas potenciales ve en el cambio casual de salida externa? Menciónelos. 

b. Explique en un párrafo cómo pueden diferir en apariencia y función la salida interna 
y externa. 

2. "No necesito verlo muy seguido, pero cuando lo hago, debo poder llegar a él rápida¬ 
mente. Pienso que perdimos el último contrato porque la información que necesitaba 
se perdió en una pila de papel en alguna parte del escritorio de alguien", dice Luke Alo- 
ver, un arquitecto que describe los problemas de la compañía a uno de los analistas 
asignados al nuevo proyecto de sistemas. "Lo que necesito es información urgente acer¬ 
ca de cuánto costó una construcción en pies cuadrados la última vez que participamos 
en una licitación; cuánto cuestan ahora los materiales básicos tales como acero, vidrio y 
concreto con nuestros tres proveedores principales; quién seria nuestra competencia 
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probable en este tipo de construcción, y quién integra el comité que tomará la decisión 
final de quien gana la licitación. Sin embargo, ahora mismo hay cien informes en algu¬ 
na parte. Tengo que examinar todo para encontrarlo." 

a. Dados los detalles limitados que tiene aquí, escriba un párrafo para sugerir un mé¬ 
todo de salida para el uso de Luke que resolverá algunos de sus problemas actua¬ 
les. En un segundo párrafo, explique sus razones por las que hizo esa elección del 
método de salida. (Sugerencia: asegúrese de relacionar el método de salida con el con¬ 
tenido de salida en su respuesta.) 

b. La idea actual de Luke es que no es necesario mantener ningún registro impreso de 
salida. En un párrafo, discuta qué factores se deben pesar antes de usar la salida en 
pantallas para la exclusión de informes impresos. 

c. Haga una lista de cinco a siete preguntas acerca de la función de la salida en la 
organización que le preguntaría a Luke y otros antes de decidir anular cualquier 
informe impreso que se use actualmente. 

3. Aquí hay varias situaciones que requieren decisiones sobre el contenido de la salida, la 
metodología de la salida, la distribución, etc. Para cada situación, escriba la decisión de 
cuál es la salida adecuada. 

a. Un proveedor grande y respetuoso de materias primas importantes para el proceso 
de producción de su compañía requiere un informe de resumen a fin de año de los 
totales comprados por él. 

b. Los memorándums internos circulan a través del personal con respecto a los planes 
para un día de campo de la compañía. 

c. Un tomador de decisiones importante necesita un informe de resumen de la si¬ 
tuación financiera de la compañía para presentar una propuesta a inversionistas 
potenciales. 

d. El personal de la recepción del hotel necesita una lista de las reservaciones de cuartos 
de la noche actual. 

e. La policía local necesita una lista de las reservaciones de cuarto de hotel de esta 
noche. 

f. Una cuenta, en tiempo real, de las personas que entran a Wallaby World (un parque 
temático australiano) será utilizada por las patrullas del estacionamiento. 

g. Un sistema de inventario debe registrar un artículo cada vez que se ha examinado 
por el personal. 

h. Un informe de resumen de aumentos de paga por mérito asignado a cada uno de 
los 120 empleados se usará por 22 supervisores durante la reunión de supervisores y 
subsecuentemente para explicar los aumentos de paga por mérito a los propios 
empleados departamentales de los supervisores. 

i. Tres diseñadores estratégicos de la organización necesitan la información competi¬ 
tiva, pero es muy secreta para distribuirse ampliamente. 

4. "Creo que ahora sé qué quería ese socio, pero me confundió por un minuto", dice la 
señorita deLimit. Ella está discutiendo un prototipo de salida en pantalla diseñado por 
el analista de sistemas que ella acaba de ver. "Quiero decir, nunca lo consideré un proble¬ 
ma si aun tanto como 20 por ciento del tamaño de la clase total no pudiera acomodarse 
en una clase", ella dice. "Sabemos que nuestras clases están en demanda, y que no 
podemos contratar más profesores para cubrir las áreas que necesitamos, el ajuste se 
debe hacer en la demanda de los estudiantes. El ha resaltado como un problema si tan 
sólo 5 por ciento de los estudiantes que quieren una clase no pueden entrar, pero está 
bien. Ahora que sé lo que quiere decir, tan sólo lo ignoraré cuando la computadora 
emita un bip." 

a. En una frase o dos, describa el problema que la señorita deLimit está experimen¬ 
tando con la pantalla. 

b. ¿Su solución para "ignorar los bips" es razonable dado que la salida está en la fase 
de prototipo? 
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c. En un párrafo, explique cómo se puede cambiar la pantalla para este problema 
particular de modo que refleje mejor las reglas del sistema que la señorita deLimit 
está usando. 

5. A continuación se presenta una hoja de registro para un sistema de información de 
paciente usado por enfermeras en una casa de convaleciencia para registrar las visitas 
a pacientes y las actividades durante sus turnos. Diseñe un informe impreso que usa 
software de diseño de formulario que proporciona un resumen de la enfermera a cargo 
de cada turno y un informe para las activiades del coordinador al final de una semana. 
Asegúrese de usar las convenciones adecuadas para indicar los datos fijos, datos varia¬ 
bles, etc. Estos informes se usarán para determinar los modelos de suministro de personal 
y ofertas de actividades futuras. 
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6. Diseñe la pantalla para el problema 5 mediante software de diseño de formularios. Haga 
cualquier suposición acerca de la capacidad necesaria del sistema y siga las convenciones 
de diseño de pantallas para las instrucciones en el monitor. / Sugerencia: si lo desea, puede 
usar más de una pantalla de salida.) 

a. En un párrafo, explique por qué diseñó cada informe como lo hizo en los proble¬ 
mas 5 y 6. ¿Cuáles son las diferencias principales en su método para cada uno? 
¿Los informes impresos se pueden trasladar con éxito a las pantallas sin cambios? 
¿Por qué sí o por qué no? 

b. Algunas de las enfermeras están interesadas en un sistema basado en Web que las 
familias de pacientes pueden acceder desde su casa con una contraseña. Diseñe 
una pantalla de salida para Web. En un párrafo, describa cómo se ha alterado su in¬ 
forme para que la familia de un paciente lo pueda ver. 

7. Clancy Corportation fabrica uniformes para los departamentos de policía a nivel 
mundial. Sus uniformes se escojen por muchos grupos debido a su bajo costo y el di¬ 
seño simple pero distinguido. Usted está ayudando a diseñar un DSS para Clancy 
Corporation, y ha pedido salida tabular que le ayudará a tomar varias decisiones so¬ 
bre qué diseñadores usar, dónde comercializar sus uniformes y qué cambios hacer a 
los uniformes para mantenerlos actualizados. La siguiente tabla lista algunos de los 
datos que le gustaría ver a la compañía en las tablas, incluyendo nombres de estilo 
de uniforme, un ejemplo de un grupo del comprador para cada estilo y qué estilos de 
uniformes crean los diseñadores. Prepare un ejemplo de salida tabular para pantalla 
sobre lo que incorporan estos datos acerca de Clancy. Siga las convenciones adecua¬ 
das para las pantallas de la salida tabular. Use los códigos y una clave donde sea 
apropiado. 
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Nombre de estilo 

Ejemplo de comprador 

Diseñadores 

Militar completó : 

NYPD 

Claudio; Rlaitto,: 

Melvine Miñe 

Militar medio 

LAPD 

Riaitto, Calvetti, 

Duran, Melvine Mine 

Ropa formal, ; 

\Fuerzasarmadas ¿ 0 .• 

: Claudio, Dundee, 


¿australianas -i Á :¿;;j 

i;;i "•;Meí.yjné„Mine;; ; ;;;<< . l..;*;, 

Ropa casual 

"Miami Vice" 

Johnson, Melvine Mine 


8. Clancy también está interesada en la salida gráfica para su DSS. Quiere ver una com¬ 
paración gráfica de cuántos estilos de uniforme se venden cada año. 

a. Seleccione un estilo de gráfico apropiado y diseñe un gráfico para desplegar lo que 
incorporan los datos siguientes: 

1999 militar completo (57 por ciento de todas las ventas]. 

2000 militar completo (59 por ciento de todas las ventas). 

2001 ropa casual (62 por ciento de todas las ventas]. 

2002 ropa casual (55 por ciento de todas las ventas). 

2003 ropa casual (40 por ciento) y militar medio (22 por ciento). 

Asegúrese de seguir las convenciones de diseño adecuadas para las pantallas. Si es 
necesario use los códigos y una clave. 

b. Seleccione un segundo método de graneado que podría permitir a los tomadores 
de decisiones en Clancy ver con el tiempo una tendencia en la compra de estilos de 
uniforme particulares. Dibuje un gráfico para la pantalla como parte de la salida para 
el DSS de Clancy. Asegúrese de seguir las convenciones de diseño adecuadas para las 
pantallas. Si es necesario use los códigos y una clave. 

c. En un párrafo, explique las diferencias de los dos gráficos en pantalla que ha escogido. 
Defienda sus opciones. 

9. Navegue por la Web para ver sitios Web bien diseñados y pobremente diseñados. Co¬ 
mente qué es lo que hace buenos o malos a los sitios, usando el formulario de crítica 
presentado antes en el capítulo para compararlos y contrastarlos. 

10. Proponga un sitio Web para Clancy, la compañía que describió en los problemas 7 y 8. 
Esboce a mano o use software de diseño de formularios para crear un prototipo de la 
página de bienvenida para Clancy. Indique hipervínculos e incluya un boceto de un do¬ 
cumento de hipervínculo. Recuerde incluir gráficos, iconos, e incluso sonido u otros 
medios si lo considera apropiado. En un párrafo, describa quiénes son los usuarios a los que 
va dirigido el sitio Web e indique por qué es conveniente que Clancy tenga una presencia 
en la Web. 


PROYECTOS DE GRUPO 

1. Sugiera ideas con sus miembros del equipo acerca de qué tipos de salida son más apropia¬ 
dos para una variedad de empleados de MaverickTransport. Incluya una lista de entornos 
o situaciones de toma de decisiones y tipos de salida. En un párrafo, explique por qué 
el grupo sugirió opciones particulares para la salida. 

2. Cada miembro del equipo debe diseñar una pantalla de salida o formato para las situacio¬ 
nes de salida que mencionó en el proyecto 1. (Use una herramienta CASE o un formu¬ 
lario de diseño en papel para completar cada despliegue o formulario.) 

3. Comparta cada pantalla o formulario entre los miembros de su equipo. Mejore su diseño 
usando la retroalimentación recopilada. 

4. Diseñe un sitio Web, en papel o usando software con el que ya está familiarizado, para 
Maverick Transport. Aunque puede esbozar documentos o gráficos para los hiper¬ 
vínculos en papel, cree una página de inicio prototipo para Maverick, indicando los 
hipervínculos donde sea apropiado. Obtenga retroalimentación de otros grupos en 
su clase y modifique su diseño como corresponda. En un párrafo, explique por qué 
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es diferente el diseño de un sitio Web en comparación con el diseño de pantallas para 
otros sistemas en línea. 
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IIFORIES OE LAS SALIDAS 


"Elaboremos especificaciones de la salida y vayamos hacia atrás por el flujo de datos para 
determinar los datos de entrada correspondientes", dice Anna durante su reunión con Chip. 

"Está bien", responde Chip. 

La salida se separó en dos categorías: informes y pantallas. Los informes se definieron 
aún más en informes externos, como la USER SOFTWARE NOTIFICATION (NOTIFI¬ 
CACIÓN DE SOFTWARE AL USUARIO), o en informes internos, como el HARDWARE 
INVENTORY LISTING [LISTADO DEL INVENTARIO DE HARDWARE). Cada informe 
se clasificó aún más como informe detallado, de excepción o de resumen. 

De las conversaciones con Paige Prynter, los analistas deducen que el HARDWARE 
INVESTMENT REPORT (INFORME DE INVERSIÓN EN HARDWARE) tiene la priori¬ 
dad más alta. Se requiere lo antes posible porque el proceso del presupuesto llegará pronto 
a una fase crítica y hay muchas solicitudes de hardware nuevo y de actualizaciones para el 
equipo existente. 

El proceso usado para crear el HARDWARE INVESTMENT REPORT es similar al pro¬ 
ceso para crear todos los informes. Chip examina los diagramas de flujo de datos del 
nuevo sistema y localiza el flujo de datos HARDWARE INVESTMENT REPORT. Al 
hacer doble clic en la línea del flujo de datos aparece la entrada del depósito relaciona¬ 
da con este informe, como se ilustra en la figura El 1.1, el HARDWARE INVESTMENT 
REPORT. Esta pantalla contiene una definición que proporciona información sobre el 
tipo de informe y un alias. El área Composition ofrece una lista de todos los elementos 
del informe. El área Notes proporciona información adicional necesaria para generar el 
informe. 

"Me alegro de que hayamos dedicado tiempo para documentar los informes y pantallas 
del prototipo cuando creamos los diagramas de flujo de datos", comenta Chip. "Puedo iden¬ 
tificar con facilidad los elementos necesarios para producir el informe." Chip coloca el cursor 
en los elementos del área de composición y hace clic en el botón Jump para desplegar los 
detalles de cada elemento. 

"Esto es muy importante", exclama Chip. "Fue una buena idea haber definido todos los 
elementos conforme los determinamos." 

A continuación. Chip empieza a crear un informe de muestra en Access. Después del 
primer borrador. Chip genera una vista preliminar del informe. 

"Hummm", murmura Chip. "Es necesario reestructurar algunos de los campos, y se 
requiere equilibrar el espacio horizontal." 

El diseño del informe se modifica y revisa de nueva cuenta. Al tercer intento, por fin 
se termina el informe. El siguiente paso es crucial: Chip le pide a Paige que revise el in¬ 
forme y le haga los cambios que desee. Chip pregunta: "¿Crees que falte alguna columna 
o datos que pudieran hacer más útil el informe? ¿El informe contiene todos los datos ne¬ 
cesarios?" 

Paige estudia la salida durante algunos minutos y comenta: "Se requieren subtotales para 
cada marca, incluso el número de máquinas y los totales finales. Recibimos solicitudes de 
diferentes tipos de máquinas, y conocer la cantidad de cada máquina nos ayudaría a determi¬ 
nar lo que se compra". 

Chip vuelve a su computadora y hace los cambios necesarios. El ejemplo final del 
HARDWARE INVESTMENT REPORT se muestra en la figura El 1.2. Paige revisa nueva¬ 
mente esta versión, y aprueba el diseño. 



ASPECTOS ESENCIALES DEL DISEÑO 









MVKV/r!-.K 5 yj 4 »fW|i!« 


jtém 






fC'ata-pow. ■ 




Ui/vUA A .? 1 

1 ni 2 



: :í.- 

0 



%!!?: i s* * í¿>c>: ví : '.-"r* 


íp^bh;'' JA Slinryjy tepuli- í:hr ij Ita ¡¿i'cfl.f/ilxí nr¡-4 t/'tilies oryJ afnij'. H 
’■ • ' >'• ; jil r '«rí»t.j;t Llj vl.-'J) . : ¡ "L- iH-*C !• 1 I . v r .\>-¿.'.r\'lU tpUi. 


;/Al¡á¿:..;. 1 .->r ipn*^ -'rrfmtmírf'iPir. 


mi 


Icrn L,' - j :ííiJtX■. jíj I *3 U .1 l'jTB - 

•:•Ja .-..Votin:. • ¿'.«i.. rl ■<■ 

'• í f 3 7 | JslL.trl->:rct ti°-jJ-EfiW + 
-■;•,| Hfj:}] jTota] In vested + 


" 3 . 






_‘:l 


id 


■ -.¡.Notes: . rl: r : lé>: r r c.ach Uliici l;*! : í iJV U ""«»*"il? L^li.: el n VA*: 'iUiN~.te'.ur ¡ 

í iniddit uk Vi c^modciá-iü ae*bt«*jTii:Jni ■ :f35¿t&s 0 r. h fc:mc«jel. 



LpngName: 

C?L |- C-'ejwe-|- Hext j‘ Snvr | Sc-ntnh j, Jump j . ¿te j Hirslnry j ? j 


' Á-y. ; | Clcoi .Prior Exil j Exparid f : vi :, Copy SearchCritena 


Press n h/üH 1á.;.. : : ' .v ■ 


Pantalla de flujo de datos del HARDWARE INVESTMENT REP(5RT. 


t 


La lógica de este informe de resumen se detalla en una especificación del proceso. El archi¬ 
vo COMPUTER MASTER (MAESTRO DE COMPUTADORAS) se ordena por modelo 
(MODEL) y marca (BRAND). Los registros se leen del archivo COMPUTER MASTER, y se 
acumulan los totales de cada marca y modelo. Cuando cambian la marca o el modelo, se impri¬ 
me una línea de informe. Cuando ocurre un cambio en la marca, se imprimen los subtotales de 
la marca. Los totales finales se imprimen después de que se procesan todos los registros. 

Anna conversa un poco con Cher Ware acerca de lo que esta última necesita de un in¬ 
forme. Cuando Cher realiza la siguiente pregunta, se bosquejan diversos informes impresos: 
"¿Podré ver rápidamente en la pantalla de la computadora informes con la información más 
reciente?" 

La conversación siguiente da como resultado la creación de diversos informes para 
despliegue. 

"¿Cómo te gustaría ver las categorías del software?", pregunta Anna. "¿Te gustaría ver 
todo el software en una sola pantalla que se pueda desplazar?" 
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Xxxxxxxxxxxx 


Xxxxxxxxxxxxxx 


Xxxxxxxxxxxxxx 


Xxxxxxxxxxxxxxxx 


Xxxxxxxxxxxxxxxx 


Hardwarejnvestment Report 


Xxxxxxxxxxxxxxxxxx 


Xxxxxxxxxxxxxxxx 


Xxxxxxxxxxxxxxxxxx 


Xxxxxxxxxxxxxxxx 


Xxxxxxxxxxxxxxxxxxxx 


Brand Subtotal 


Brand Subtotal 


Brand Subtotal 


Numberof 

Machines 


$79,992.00 




— 


Ejemplo de la salida final de HARDWARE INVESTMENT REPORT. 


"Bueno, me gustaría contar con algún medio para buscar una categoría y desplegar todo 
el software disponible para la misma", contesta Cher. "También sería muy útil tener la facili¬ 
dad de desplazarme entre las categorías siguientes y las anteriores." 

Anna trabaja con el depósito de Visible Analyst para el flujo de datos SOFTWARE BY 
CATEGORY (SOFTWARE POR CATEGORÍA], que se muestra en la figura El 1.3. Anna 
introduce el contenido de la pantalla y redacta algunas notas acerca de las cosas adicionales 
que se requieren para generar un programa funcional. 

Anna crea la pantalla SOFTWARE BY CATEGORY mediante un formulario de Ac¬ 
cess, como se muestra en la figura El 1.4. Hay un botón para buscar registros, así como 
botones para desplazarse a las categorías anteriores y las siguientes. En la parte inferior de la 
pantalla hay un área para mostrar varios paquetes de software para la categoría. El campo 
OPERATING SYSTEM se guarda como un código en la tabla correspondiente de la base de 
datos y se convierte en la descripción del código en la pantalla. 

Anna muestra a Chip y Cher la pantalla final. "Estoy impresionada", exclama Cher. 
"[Esto es exactamente lo que necesito!" 

En ese momento entra Ian Perteks: "¿Qué ocurre?", pregunta. Después de ver la panta¬ 
lla, comenta: 'Yo estoy participando en el proyecto de la intranet. ¿Se puede obtener alguna 
información colocada en tina página Web?" 

"¿Qué has pensado?", pregunta Chip. 

"Bueno, he estado pensando en esto", contesta Ian. "Creo que sería útil tanto para los 
profesores como para el personal contar con una forma de consultar información relacionada 
con los cursos de software que planeemos impartir. Posteriormente podríamos incorporar un 
formulario en la intranet para que pudieran inscribirse a los cursos." 
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Pantalla que despliega el flujo de datos de SOFTWARE BY CATEGORY. 


"He oído mucho acerca de la intranet y he creado algunos prototipos para ella", comen¬ 
ta Chip. "[Ése sería un proyecto divertido para trabajar! Podríamos incluir un vínculo a la 
página desde nuestros menús de Soporte de Tecnología." 

"Cuenta conmigo", interviene Anna. "He creado algunas páginas Web por mi cuenta. 
¿Qué deseas poner en la página?" 

"Me gustaría crear una página principal que muestre los cursos, además de otras páginas 
que indiquen el nivel, como principiante o intermedio, del curso y las fechas de inicio de 
los cursos", contesta Ian. 

Chip y Anna se dedican a trabajar en la página Web. Los campos se identifican y agrupan 
en el flujo de datos TRAINING CLASSES OFFERED [CLASES DE CAPACITACIÓN 
OFRECIDAS], el cual se muestra en la figura El 1.5. Observe que la dirección Web se inclu¬ 
ye en forma de alias. Anna crea la página Web definitiva para la intranet, tal como se ilustra 
en la figura El 1.6. Chip y Ian revisan la página. 
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Titls 

Versión 

Operating System 

Publisher 

Site 

License 

Number 
of Copies 


Visible Analyst 

7.5 

Windows 98 

Visible Systems 

• 

40 


Visio 

10.D 

Windows 90 

Microsoft 

D 

40 


ArgollML 

1 

Windows 98 

Argo 

• 

10 
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Pantalla del formulario de Access de SOFTWARE BY CATEGORY. 


"Me gustan los menús en la parte superior de la página y el submenú con las característi¬ 
cas específicas que se despliega abajo de los menús", comenta Chip. 

"El calendario es muy útil para que el personal vea los cursos programados por fecha, 
con botones para cambiar el mes y el año", indica Ian. 

"Sí, y creo que también es muy bueno darle al personal la facilidad de cambiar la forma 
en que se despliegan los datos. A muchos miembros del personal les gusta ver los cursos que 
se ofrecen en su campus", agrega Chip. 

"Se vería más atractivo si agregáramos una imagen de la mascota", añade Ian, "y el lema 
de la universidad". 

"Trabajaré en esto", contesta Anna. "Éstas sugerencias son muy buenas." 

La pantalla final de la intranet se termina y Ian la aprueba. 

"Mandaré un correo electrónico a todos los profesores y el personal", comenta Ian. 
"Gracias por incluir mi dirección de correo electrónico. Esto ayudará a facilitar el registro a 
los cursos y a contestar las preguntas que surjan. iCreo que realmente estamos progresando!" 

Usted puede realizar los siguientes ejercicios diseñando el informe o la pantalla me¬ 
diante formularios de diseño, o usando cualquier procesador de textos que conozca. Los 
campos y otra información relacionada con los informes se encuentran en las entradas del 
depósito de flujo de datos de Visible Analyst. En cada ejercicio se mencionan los nombres 
de los flujos de datos. 

Se han creado los informes y pantallas correspondientes (conocidos como formularios 
en Microsoft Access). Toda la información se encuentra en la base de datos de Microsoft 
Access; usted sólo tiene que modificar los informes y pantallas existentes para generar las 
versiones finales. Las modificaciones se realizan seleccionando el informe o pantalla deseado 
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Pantalla que despliega el flujo de datos de TRAINING CLASSES OFFERED. 


y haciendo clic a continuación en el botón Design [Diseño]. Se pueden hacer las siguientes 
modificaciones. El Page Header contiene los títulos de las columnas. El área Detail contiene 
los campos impresos del informe. 

Haga clic en un campo para seleccionarlo. Para seleccionar varios campos, haga clic en 
cada uno oprimiendo al mismo tiempo la tecla de mayúsculas. 

Arrastre un campo [o campos] seleccionado[s] para moverlo(s]. 

Haga clic en cualquiera de los pequeños cuadros que rodean a un campo para cambiar 
el tamaño del mismo. 

Seleccione varios campos y haga clic en el botón Format y elija alguno de los siguientes 
comandos: 

Align, para alinear todos los campos en la parte superior, a la izquierda, etcétera. 
Size, para igualar la anchura o altura de los campos. 

Horizontal Spacing, para igualar el espaciado horizontal, o aumentar o disminuir el 
espaciado. 

Vertical Spacing, para igualar el espacio vertical, o aumentar o disminuir el espaciado. 
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Página Web para la intranet de la Central Pacific University. 


EJERCICIOS 

E-l. Use Access para ver el HARDWARE INVESTMENT REPORT. Si ya conoce Access, 
use el comando Export [Exportar) del menú File (Archivo) para guardar el informe 
como página Web. Cuando aparezca el cuadro de diálogo Export, haga clic en la lista 
descendente Save As Type (Guardar como tipo) y elija HTML Documents (Docu¬ 
mentos HTML). 

E-2. Chip, Dot y Mike participaron en varias sesiones de lluvia de ideas que dieron 
como resultado el bosquejo de varios informes. Diseñe (o modifique con Access) 
el HARDWARE INVESTMENT REPORT. Este informe es grande, por lo que us¬ 
ted deberá tener cuidado de incluir todos los datos en el área del informe. Tal vez 
necesite redactar varias líneas detalladas para cada registro. Imprima el informe 
final. 

E-3. Después de reunirse con Cher Ware y Ian Perteks para discutir los informes que re¬ 
quieren, Anna ha identificado los campos para el informe parcial NEW SOFTWARE 
INSTALLED REPORT. Diseñe (o modifique) el informe de tal forma que incluya 
los elementos del flujo de datos encontrados en la entrada del depósito. ¿Se trata de 
un informe de resumen o uno detallado? En un párrafo, describa la lógica que usted 
considera que debe usar el programa que produce los informes. 


Los ejercicios precedidos por un ¡cono Web indican que en el sitio Web del libro hay material de valor 
agregado. Los estudiantes pueden descargar una base de datos de Microsoft Access que pueden utilizar 
para completar los ejercicios. 
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Dot y Mike necesitan saber cuándo se han recibido nuevas computadoras. Genere el 
informe NEW COMPUTER RECEIVED REPORT. El flujo de datos COMPUTER 
RECEIVED REPORT contiene los elementos necesarios. 

Diseñe el informe SOFTWARE MASTER REPORT con información que ayude a 
Cher y Ian a localizar fácilmente todas las copias de cualquier paquete de software. 
Los elementos necesarios para producir el informe se encuentran en el flujo de datos 
SOFTWARE MASTER REPORT. 

Los campos TITLE, VERSIÓN, OPERATING SYSTEM ÑAME, PUBLISHER, 
CATEGORY, y FIRST y LAST ÑAME del software se deben imprimir en conjunto. Se 
deben incluir totales para cada combinación de TITLE/OPERATING SYSTEM/ 
VERSIÓN. Imprima el diseño final del informe. 

Diseñe el informe HARDWARE INVENTORY LISTING, de tal manera que muestra 
el software disponible en cada sala de cada campus. El campo CAMPUS debe ser 
la CAMPUS DESCRIPTION, no el código que representa al campus. 

. Diseñe el informe INSTALLED COMPUTER REPORT, de tal manera que muestra 
las computadoras personales que se hayan instalado en cada sala. Use el campo 
CAMPUS DESCRIPTION e imprima de manera conjunta los campos CAMPUS 
DESCRIPTION y ROOM LOCATION. El campo INSTALLED BOARDS es un 
grupo de repetición, con hasta cinco entradas por computadora. 

Utilice Access para ver la pantalla del informe SOFTWARE BY CATEGORY. Haga 
clic en el botón Find (Buscar) y localice el conjunto de herramientas CASE. Haga clic 
en los botones Next (Siguiente) y Previous (Anterior) para ver las Categorías de 
software correspondientes. 

Diseñe la pantalla del informe SOFTWARE BY MACHINE. Consulte los elementos 
en la entrada del depósito del flujo de datos. 

Diseñe el informe COMPUTER PROBLEM REPORT. Este informe muestra todas 
las computadoras que se han reparado en varias ocasiones o que han tenido un eleva¬ 
do costo de reparación. Consulte la descripción de los elementos del flujo de datos 
en el almacén o modifique el informe en Access. 

. Diseñe o modifique el informe INSTALLATION REPORT. Consulte los elementos 
del flujo de datos en el depósito. Este informe muestra las computadoras que se han 
recibido recientemente y cuáles se pueden instalar. 

Diseñe el informe NEW COMPUTER RECEIVED REPORT. Consulte la descripción 
de los elementos del flujo de datos en el depósito o modifique el informe en Access. 
Este informe de resumen muestra la cantidad de computadoras de cada marca y mo¬ 
delo. Estas computadoras deben desempacarse y es necesario instalarles tarjetas de 
componentes y otro hardware antes de instalarlas en las salas. 

Diseñe o modifique el informe PREVENTIVE MAINTENANCE REPORT. Consul¬ 
te los elementos del flujo de datos en la entrada del depósito. Este informe muestra 
las computadoras que requieren mantenimiento preventivo. 

Diseñe el informe SOFTWARE CROSS REFERENCE REPORT. Consulte la descrip¬ 
ción de los elementos del flujo de datos en el depósito o modifique el informe en Ac¬ 
cess. Este informe muestra la computadora en que se encuentra instalado cada paquete 
de software. Los campos TITLE, VERSIÓN, OPERATING SYSTEM MEANING y 
PUBLISHER se imprimen de manera conjunta. Las líneas de detalle abajo del grupo 
contienen datos que muestran la máquina, el campos y la sala. 

Diseñe o modifique el informe OUTSTANDING COMPUTER PURCHASE OR- 
DERS REPORT. Consulte los elementos del flujo de datos en la entrada del depósi¬ 
to. Este informe se podría generar para todos los registros PURCHASE ORDER que 
tengan un código de orden de compra MI01, el cual indica computadoras, con la 
condición adicional de que el campo QUANTITY ORDERED del registro debe ser 
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mayor al campo QUANTITY RECEIVED. Indique en un párrafo si este informe es 
de resumen, de excepción o detallado. 

E-16. Diseñe el informe SOFTWARE INVESTMENT REPORT. Consulte la descripción 
de los elementos del flujo de datos en el depósito o modifique el informe en Access. 









OBJETIVOS DE APRENDIZAJE >r' 

Una vez que haya dominado el material de este capítulo, podrá:: 

1. Diseñar formularios de entrada funcionales para los sistemas de negocios; 

2. Diseñar pantallas de entrada atractivas para los sistemas de ihformación. 

3. Diseñar formularlos de entrada útiles para la Web. 

■■ 4. Diseñar páginas de entrada para utilizar en ¡ntranets e Internet. 


la calidad di. V mitrada dol. sistoma determina la calidad do la salida dol mismo. \fs vilal 
dm- los formúlanos do ontrada la^ pantallas 1 y los-don milenios Web ínterin uvos se diseñen 
tomando on cuenta eslu importante relación. . ■:■. . : : 

(5i,íftdo r.stan biibi di diñaiki.f iqs foímulnñO'-jdi cmrada, I;;'¿ panlnlkis y los formúlanos 
irli"J'acuvos para Itiniñsl, 1 bi la Woh.utbon safisracor los ohirjivo s dó o;\\u\id;tii. proa 
;-iún, Jjr'iliihul di' usó. forisisÜ'ncia- .simplicidad; ¡i;rjcii\d. : 7 T'oi.ins ríms ohiolivos, sv juiodon 
ICv A r.¡r sig'ijiondo principios básicos do diseño, sabiondo c¡uó ñt.Vof.ita oí sisiema tiimii t'nlra- 
da y entendiendo cómo respoñden los usuarios a los diversos elementos de los formularios, 
y las pantallas. . ' 

Efectividad quiere decir que los formularios de entrada, las pantallas de entrada y ios 
formularios para cóñtestar en la Web cumplen propósitos específicos en el sisu-ni; 1 .do infir¬ 
mación, mientras qüedá precisión se. refiere al diseño que garantiza que se con tostarán de 
manera apropiada. La facilidad de uso significa que los formularios y las pantallas son .sen¬ 
cillos y no se. requiere tiempo adicional para descifrarlos. La consistencia implica iliu: todos 
los formularios de entrada, independientemente de que sean pantallas de entrada o formu¬ 
larios para contestar én la Web, agrupan los datos dé forma semejante de un» aplicación a 
otra, mieñtras que.lá simplicidad se refiere a mantener limpios estos mismos dísonas con o! 
propósito de atraer la atención del usuario. El atractivo implica que los usuarios disínitarán 
al usar los formularios de entrada gracias a lo interesante de su diseño. 

díseno .; ,: : 

El analista de sistemas debe contar con la capacidad para diseñar formularios completos: y 
útiles. Es necesario eliminar los formularios innecesarios que desperdicien los nvursos lio 
una organización. : "¡. . '1 ¡ •' n •' ■ 

Los formularios son instrumentos importantes para dirigiré! curso del trakiip. Son do¬ 
cumentos previamente impresos que requieren respuestas estandarizadas por parto do los 
usuarios. Los formularios obtienen y capturan información solicitada por los miombro.-r do 






































la organización, que con frecuencia servirá de entrada a la computadora. A través de este 
proceso, los formularios sirven a menudo como documentos de origen para el personal de 
captura de datos o como entrada para las aplicaciones de comercio electrónico. 

Para diseñar formularios útiles, es necesario ceñirse a los cuatro lincamientos siguientes: 

1. Haga formularios fáciles de contestar. 

2. Asegúrese de que los formularios cumplen el propósito para el cual se diseñaron. 

3. Diseñe formularios para garantizar que se contesten con precisión. 

4. Mantenga atractivos los formularios. 

Cada uno de estos cuatro lincamientos se considera por separado en las siguientes secciones. 


CREACIÓN DE FORMULARIOS FÁCILES DE CONTESTAR 

Para reducir los errores, acelerar el llenado y facilitar la entrada de datos, es esencial que los 
formularios sean fáciles de contestar. El costo de los formularios es mínimo en comparación 
con el costo del tiempo que los empleados dedican a contestarlos y a ingresar los datos co¬ 
rrespondientes en el sistema de información. Con frecuencia es posible eliminar el proceso 
de transcribir al sistema los datos que se capturan en un formulario recurriendo al envío por 
medios electrónicos. Con este método a menudo es necesario que los usuarios introduzcan 
datos por sí mismos, a través de sitios Web configurados para realizar transacciones con pro¬ 
pósitos informativos o de comercio electrónico. 

Flujo del formulario El diseño de un formulario con el flujo apropiado puede minimizar el 
tiempo y el esfuerzo que dedican los empleados para contestarlo. Los formularios deben 
fluir de izquierda a derecha y de arriba abajo. El flujo carente de lógica requiere tiempo adi¬ 
cional y es frustrante. Un formulario que requiere ir directamente al fondo y regresar al 
principio para contestarlo refleja un flujo pobre. 

Siete secciones de un formulario Un segundo método que facilita a los usuarios contestar 
correctamente los formularios es el agolpamiento lógico de la información. Las siete seccio¬ 
nes principales de un formulario son las siguientes: 

1. Encabezado. 

2. Identificación y acceso. 

3. Instrucciones. 

4. Cuerpo. 

5. Firma y verificación. 

6. Totales. 

7. Comentarios. 

Estas secciones deben aparecer agrupadas en una página como se muestra en la figura 12.1. 
Observe que las siete secciones cubren la información básica requerida en la mayoría de los 
formularios. La cuarta parte superior del formulario se dedica a tres secciones: el título, la 
sección de identificación y acceso, y la sección de las instrucciones. 

La sección del título normalmente incluye el nombre y dirección del negocio que origi¬ 
na el formulario. La sección de identificación y acceso incluye códigos que pueden usarse 
para archivar el informe y acceder a él posteriormente. (En el capítulo 13 explicamos en 
detalle cómo acceder a información especialmente codificada en una base de datos.) Esta 
información es muy importante cuando se requiere que una organización guarde el docu¬ 
mento un número determinado de años. La sección de las instrucciones dice cómo debe 
contestarse el formulario y a dónde debe enviarse cuando se complete. 

La parte media del formulario constituye su cuerpo. Esta parte del formulario requiere 
el mayor detalle y desarrollo por parte de la persona que lo contesta. El cuerpo es la parte 
del formulario que con mayor probabilidad contendrá datos variables. 

La cuarta parte inferior del formulario está compuesta por tres secciones: firma y veri¬ 
ficación, totales y comentarios. Al requerir totales finales y un resumen de comentarios se 
da a la persona que contesta el formulario una manera lógica de terminarlo. 
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En los formularios bien, 
diseñados se pueden encontrar 
siete secciones. 



Títulos La creación de títulos claros es otra técnica que puede facilitar la tarea de contes¬ 
tar un formulario. Los títulos le indican a la persona que contesta el formulario qué poner 
en una línea, espacio o cuadro en blanco. En la figura 12.2 se muestran varias opciones para 
crear títulos: dos tipos de títulos con líneas, dos tipos de títulos con casillas, y ejemplos de tí¬ 
tulos en recuadros y títulos en tabla. 

La ventaja de poner el título abajo de la línea es que hay más espacio en la propia línea 
para los datos. La desventaja es que a veces no es claro qué línea está asociada con el título: 
la línea arriba o abajo del título. 

Los títulos con líneas pueden colocarse a la izquierda con espacios en blanco y en la 
misma línea, o pueden disponerse abajo de la línea en la cual se ingresarán los datos. 

Otra manera para colocar títulos es dentro de un recuadro en lugar de con una línea. 
Los títulos pueden ponerse dentro, arriba o abajo del recuadro. Los recuadros son útiles 
en los formularios para que los usuarios ingresen los datos en el lugar correcto, e incluso fa¬ 
cilitan la lectura al destinatario del formulario. Es importante utilizar un tamaño de fuente 
pequeño para el título de tal manera que no domine el área de entrada de datos. Se pueden 
incluir marcas verticales en el recuadro si se planea que los datos sirvan de entrada en un sis¬ 
tema de cómputo. Si no hay suficiente espacio en un registro para los datos, la persona que 
contesta el formulario, en vez del operador que captura los datos, tiene libertad para abre¬ 
viar los datos. Los títulos también pueden incluir notas para ayudar al usuario a ingresar 
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Principales alternativas para 
colocar títulos. 




Teléfono 


•. Título en recuadro. 




correctamente la información, como Fecha (MM/DD/AAAA] o Nombre (Apellido, Nom¬ 
bre, Inicial del Segundo Nombre]. 

Independientemente del estilo de título con líneas que se elija, es importante emplear¬ 
los de forma consistente. Por ejemplo, es confuso contestar un formulario que tenga títulos 
tanto arriba como abajo de la línea. 

Los títulos con casillas son la mejor opción cuando es necesario restringir las opciones 
de respuesta. Observe la lista de métodos de viaje que se muestra en el ejemplo de elección 
vertical de la figura anterior. Si sólo se reembolsan al empleado los gastos de viajes de nego¬ 
cios para los métodos de viaje listados, un sistema de elección vertical es más conveniente 
que una línea en blanco. Este método tiene la ventaja adicional de recordar a la persona en¬ 
cargada de verificar los datos que busque un talón de boleto de avión u otro recibo. 
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Un título con casillas horizontales también es mejor que un título con líneas cuando la in¬ 
formación que se requiere es rutinaria y constante. Un ejemplo es un formulario que solicite 
los servicios de uno de los departamentos siguientes: el Laboratorio fotográfico, el Departa¬ 
mento de impresión. Mantenimiento o Suministros. Los departamentos proporcionan servicios 
de manera rutinaria a otros en la organización y es poco probable que cambien con rapidez. 

Los títulos de tabla son adecuados en el cuerpo de un formulario donde se requieren 
detalles. Cuando un empleado contesta correctamente un formulario con títulos de tabla, 
está creando una tabla para la próxima persona que recibe el formulario, con lo cual colabora 
a organizar coherentemente los datos. 

Una combinación de títulos también es eficaz. Por ejemplo, los títulos de tabla se pue¬ 
den usar para especificar categorías como la cantidad, y los títulos con líneas pueden utili¬ 
zarse para indicar dónde deben colocarse el subtotal, el impuesto de ventas y el total. Puesto 
que los diversos títulos tienen diferentes propósitos, por lo general es necesario emplear va¬ 
rios estilos de título en cada formulario. 

SATISFACCIÓN DEL PROPÓSITO PREVISTO 

Los formularios se crean para satisfacer uno o más propósitos en el registro, el procesamiento, 
el almacenamiento y la recuperación de información de las empresas. A veces es conveniente 
proporcionar información diferente a cada departamento o usuario, aunque compartiendo un 
poco de información básica. En estos casos es donde son útiles los formularios especializados. 

El término formulario especializado también puede referirse tan sólo a la manera en 
que la imprenta prepara los formularios. Entre los ejemplos de formularios especializados 
están los formularios de múltiples partes que se usan para crear triplicados instantáneos de 
los datos, los formularios continuos que corren por la impresora sin intervención del usua¬ 
rio, y los formularios perforados que tienen un talón desprendióle que sirve como registro. 

CÓMO ASEGURAR LA CONTESTACIÓN PRECISA 

Las tasas de error asociadas a la recopilación de datos descenderán considerablemente cuando 
los formularios se diseñen para garantizar su contestación precisa. El diseño es importante 
para lograr que los usuarios hagan lo correcto con el formulario siempre que lo utilicen. 
Cuando los empleados de servicios, como los encargados de tomar la lectura del consumo 
de energía eléctrica o los administradores de inventarios, usan dispositivos portátiles para 
examinar o teclear datos en el sitio apropiado, se evita el paso adicional de la transcripción 
durante la captura de los datos. Los dispositivos portátiles usan la transmisión inalámbrica, 
o se conectan a sistemas de cómputo más grandes en los que pueden descargar los datos que 
haya recopilado el empleado de servicios. En estos casos no se requiere una transcripción 
adicional de lo que haya ocurrido en el campo. 

El comprobante de gastos de empleados de Bakerloo Brothers, que se muestra en la fi¬ 
gura 12.3, se acerca mucho a garantizarla contestación precisa de un formulario. Muchas de 
las técnicas de diseño de formularios que hemos discutido se usan en este ejemplo de com¬ 
probante de gastos. El diseño del formulario implementa el flujo correcto: de arriba abajo y 
de izquierda a derecha. También se apega a la idea de siete secciones o categorías de infor¬ 
mación principales. Además, el comprobante de gastos de empleados refleja una combina¬ 
ción bien definida de títulos e instrucciones. 

Dado que a los empleados de Bakerloo Brothers sólo se les reembolsan gastos reales in¬ 
curridos, es fundamental obtener el total de gastos correcto. El diseño del formulario pro¬ 
porciona un doble mecanismo de verificación interno, con totales de columnas y totales de 
filas cuyas sumas deben coincidir. Si los totales de las filas y los de las columnas no coinci¬ 
den, el empleado que contesta el formulario sabe que hay un problema y puede corregirlo 
al momento. De esta manera se evitan los errores y el empleado obtiene el reembolso que 
se le adeuda; ambos resultados se consiguen gracias a un diseño apropiado del formulario. 

CÓMO HACER FORMULARIOS ATRACTIVOS 

Aunque el atractivo de los formularios se deja para el final, esto no significa que tiene menos 
importancia. Más bien, se hace al último porque la tarea de dar atractivo a los formularios 
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se realiza aplicando las técnicas que vimos en las secciones anteriores. Los formularios esté¬ 
ticos atraen a las personas y motivan a contestarlos. 

Los formularios deben tener una apariencia ordenada. Para ser atractivos, los formularios 
deben recabar la información en el orden previsto: la convención indica que se debe pedir 
nombre, calle, ciudad, estado y código postal (e incluso país, si fuera necesario). El diseño y 
flujo apropiados contribuyen al atractivo de un formulario. 

El uso de diversos tipos de letra en el mismo formulario puede motivar a contestarlo. 
La separación de categorías y subcategorías con líneas gruesas y delgadas también puede 
acrecentar el interés en el formulario. Los tipos de letra y el grosor de las líneas son elemen¬ 
tos de diseño útiles para captar la atención del usuario y darle la seguridad de que contesta¬ 
rá correctamente el formulario. 


DISEÑO DE FORMULARIOS POR COMPUTADORA 

Existen numerosos paquetes de diseño de formularios para PCs. En la figura 12.4 se men¬ 
cionan algunas de las características del software de diseño de formularios electrónicos e 
impresos. 
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\ ESTE FORMULARIO PODRIA SER DANINO 
JIPARA SU SALUD 


La figura 12.C1 es un formulario de historial médico impreso que el 
doctor Mike Robe, un médico familiar, da a su recepcionista para que lo 
entregue a todos los pacientes nuevos. Todos los pacientes;deben con¬ 
testarlo antes de ver al doctor. 

La recepcionista recibe muchos formularlos incompletos o con res¬ 
puestas confusas que dificultan al doctor Robe revisarlos y entender por 
qué el nuevo paciente acude a él. Además, las respuestas Incompletas 
provocan que la recepcionista invierta demasiado tiempo para registrar 
a los nuevos pacientes. 


Redlseñe el formularlo en papel tamaño carta para que los datos relati¬ 
vos a los nuevos pacientes se recopilen de una manera lógica e inofensiva. 
Asegúrese de que el formulario sea suficientemente claro para los nuevos 
pacientes. También debe ser fácil de leer para el doctor Robe y facilitar a 
la recepcionista Ingresarlo a la base de datos de pacientes, que se orde¬ 
na por nombre del paciente y número de Seguro Social. La oficina cuenta 
con PCs conectadas mediante una red de área local. ¿Cómo tendría que 
redlseñarel formulario para que la recepcionista pueda enviarlo electró¬ 
nicamente? ¿Qué procedimientos de oficina tendría usted que cambiar? 


Formulario de historial médico 

Empleo j ‘ - l T¿' 
-Teléfono.. %• 


/Plreccidn 

Asegurador; __ - ■ 

m ~ ; . ... -.esta SS 

Cruzam/ [ ] Servicio médico gubam; 


H su F#za ,vf ]V.a pofjza de su- cónyuge: 

lamenta; f J Otro | ] (estauo , __ 


i ¿Le han practicado alguna cirugía? Si 
Describa la cirugía: V < 


*í r! íÜÍ“-a<!rrtiatiya, ¿cuándo? 


. ¿haestapc -ose •.al zado 9 Sí 

' t ’ \\ .. :;*! 

¿Porqué? ;• L-.: ’• . 1 ' 


-En caso afirmativo ¿cuándo? 


Complete lo siguiente. 


HelenidO 


Diabetes. i , 

Proclo^as ce estezó" 
Cáncer ..I 

Convulsiones-., ■ ; 
Desmayos 


Historial familiar: 


,Qué vaaras ha recibido 7 


Familia , 

Cónyuge o pariente cercano jS55¿r ~ 

Fecha del ultimo examen ' ■■ .o ; ,„i 

Y:. — — ¿Quien le recomendó? 


Dirección 


¿Por qué vino ai médico hoy 7 


¿Tiene algún dolor en este momento?. 


Constante 


Esporádico. 


Por favor denos 


uPnr cuánto tiempo lo h a padecido 7 

i'IVPOST/tJlTE! Necesítenme nf níim 


su numero de.Seguro Social 


correcto ne su asegurador 


FISUR, 


Su ayuda en el perfeccionamiento de este formulario; es muy; apreciada 
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ti software para e¡ diseño ae 
formularios electrónicos tiene 
muchas características 
dinámicas. 


Características del software para el diseño de formularios electrónicos 


• Permite diseñar formularios impresos, formularios electrónicos o formularios basados 
en la Web usando un paquete integrado ■ 

• Facilita el diseño de formularios mediante plantillas 

• Permite diseñar formularios cortando y pegando formas y objetos conocidos 

• Facilita la contestación de formularios electrónicos mediante el uso de un paquete 
de software de captura de datos 

• Permite la personalización dé la contestación de formularios electrónicos con la capacidad 
para personalizar menús, barras de herramientas, teclados y macros 

• Soporta la integración con bases de datos populares 

• Facilita el envío y la transmisión de formularios electrónicos 

• Permite la transferencia secuencial de formularios 

s Ayuda a dar seguimiento a formularios transferidos a otras áreas 

• Favorece la transmisión y el procesamiento automáticos (tecnología de actualización 
automática para formularios) 

• Permite el desarrollo de bases de datos que muestran las relaciones entre las personas 
y los tipos de información (roles) 

• Establece protección de seguridad para formularios electrónicos 

• Digitaliza formularios impresos y permite su publicación en la Web 

• Crea campos electrónicos automáticamente a partir de los formularios impresos digitalizados 

• Facilita la contestación de formularios en la Web 

• Permite la realización automática de cálculos 


La figura 12.5 es un ejemplo de pantalla de computadora creada con el software Om- 
niForm de ScanSoft. Este software es de gran utilidad para un analista que busca automati¬ 
zar rápidamente procesos de negocios para los cuales ya existen formularios impresos. Los 
formularios impresos pueden digitalizarse y después publicarse en la Web. El analista puede 
usar un conjunto de herramientas para preparar campos, casillas de verificación, líneas, cua¬ 
dros y muchas otras características. 

La figura 12.6 muestra el proceso de digitalización. La parte inferior de la pantalla dividi¬ 
da muestra el formulario tal como fue digitalizado, y la parte superior muestra una vista am¬ 
pliada de algunos de los campos que el software identificó automáticamente. Después de digi- 
talizar un formulario, el analista utiliza un asistente para corregir, mejorar, identificar campos y 
cambiar el orden de tabulación para que el formulario se pueda utilizar electrónicamente. 


OmniForm de ScanSoft permite 
al usuario tomar un formulario 
existente, digitalizado en la 
computadora y definir campos 
con el fin de que el formulario 
se pueda contestar fácilmente 
en una PC. 
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La funcionalidad del formulario se amplía porque OmniForm crea automáticamente 
nombres para los campos de los formularios que se digitalizan. Cuando se activa de este 
modo, el software despliega en color verde los campos creados. En el lado izquierdo de la 
pantalla aparece una descripción de la función de creación de campos de este software. 
Esta función puede acelerar considerablemente la automatización de procesos estándar en 
situaciones en las cuales el tiempo es limitado y el deseo de innovaciones también podría 
estar limitado. 

Una vez que se digitaliza un formulario, se puede modificar y publicar fácilmente en la 
Web. Actualmente, ScanSoft ofrece un servicio de alojamiento de formularios llamado 
eOmniForm.com, en el que usted puede almacenar hasta 10,000 registros llenos en el sitio 
Web. Este servicio no sólo representa una ventaja en las aplicaciones de comercio electróni¬ 
co B2C, sino también en las B2B. Además de esto, los empleados tienen fácil acceso a los 
formularios de la compañía sin intervención administrativa adicional. 

Los formularios electrónicos pueden tener inteligencia. OmniForm también permite 
hacer cálculos automáticamente, de manera que los artículos puedan totalizarse y el im¬ 
puesto a las ventas pueda calcularse. También puede verificar el campo y confirmar que los 
datos se han introducido correctamente. Un ejemplo es el verificar que una fecha se ingre¬ 
sa como 99/99/9999. 


CONTROL DE LOS FORMULARIOS DE NEGOCIOS 

El control de los formularios de negocios es una tarea importante. Los negocios a menudo 
tienen un especialista para controlar los formularios, pero algunas veces este trabajo recae 
en el analista de sistemas, quien establece e implementa el control de los formularios. 

Las tareas básicas para controlar los formularios incluyen asegurarse de que cada formu¬ 
lario en uso cumple su propósito específico y que este propósito es integral para el funcio¬ 
namiento de la organización, evitando la duplicación de la información recopilada y de los 
formularios que la recolectan, diseñando formularios eficaces, decidiendo cómo reproducir 
los formularios de la manera más económica y estableciendo procedimientos que hagan dis¬ 
ponibles los formularios (cuando se necesiten] al costo más bajo posible. A menudo esto 
implica hacer disponibles los formularios en la Web para su impresión. Cada formulario de¬ 
be incluir un número único y la fecha de revisión (mes/año), independientemente de si se 
contesta y envía de manera manual o electrónica. 
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El control del trabajo de oficina es un área que el analista de sistemas aún debe encar¬ 
garse de verificar. El mejoramiento y el cambio en los sistemas de información dependen en 
gran medida de las actividades de administración de la información, muchas de las cuales se 
derivan de datos capturados originalmente en los formularios. 

OÍ SSÓ'Á DEC ÜÁDO' IE M N í ÁLLÁS’YFO R í Ü Ü RIOS' PAR ATÁ¥ ÉB 

Mucho de lo que ya hemos dicho sobre el diseño adecuado de formularios se puede aplicar 
al diseño de pantallas y al diseño de sitios Web y páginas Web. Una vez más, el analista de¬ 
be tener siempre presente al usuario al diseñar pantallas. 

Sin embargo, hay algunas diferencias y los analistas de sistemas deben esforzarse por 
comprender las cualidades específicas de las pantallas en lugar de adoptar ciegamente las 
convenciones de los formularios impresos. Una gran diferencia es la constante presencia de 
un cursor [un bloque de luz u otro tipo de puntero] en la pantalla, que indica al usuario 
cuál es la posición actual para introducir datos. Conforme los datos se teclean en la panta¬ 
lla, el cursor se mueve un carácter adelante, señalando la dirección. 

Otra diferencia principal entre los formularios electrónicos, los destinados a la Web y 
los estáticos consiste en que los diseñadores pueden incluir ayuda específica dependiendo 
del contexto en que se encuentre en cualquier formulario que se conteste electrónicamente. 
Esta práctica puede reducir la necesidad de mostrar instrucciones en cada línea, y eliminar 
en consecuencia la apariencia desordenada del formulario y las llamadas al soporte técnico. 
El uso de un enfoque basado en la Web también permite al diseñador aprovechar los hiper- 
vínculos, asegurando de esta manera que los formularios se contesten con precisión al pro¬ 
porcionar a los usuarios ejemplos a través de hipervínculos hacia formularios contestados 
correctamente. 

En esta sección presentamos lincamientos para un diseño eficaz de pantallas. Dichos li¬ 
ncamientos se presentan para ayudar en la realización de los objetivos globales del diseño 
de entrada de efectividad, precisión, facilidad de uso, simplicidad, consistencia y atractivo. 

Los cuatro lincamientos para el diseño de pantallas son importantes pero no minucio¬ 
sos. Como vio en el capítulo 11, incluyen lo siguiente: 

1. Mantener la sencillez de la pantalla. 

2. Mantener consistente la presentación de la pantalla. 

3. Facilitar el movimiento del usuario entre las pantallas y páginas desplegadas. 

4. Crear pantallas atractivas. 

En las siguientes subsecciones, desarrollamos cada uno de estos lincamientos y presentamos 
muchas técnicas de diseño para apegarse a los cuatro lincamientos. 

CÓMO MANTENER LA SENCILLEZ DE LA PANTALLA 

El primer lincamiento para el diseño adecuado de pantallas es mantener la sencillez. La 
pantalla sólo debe mostrar lo que sea necesario para emprender una acción particular. Para 
el usuario ocasional, 50 por ciento del área de la pantalla debe contener información útil. 

Tres secciones de pantalla La salida de la pantalla se debe dividir en tres secciones. La 
parte superior presenta una sección de "encabezado". El encabezado contiene los títulos 
del software y de los archivos abiertos, de menús desplegables e iconos que realizan tareas 
específicas. 

La sección media se conoce como "cuerpo" de la pantalla. El cuerpo se puede usar para 
la entrada de datos y se organiza de izquierda a derecha y de arriba abajo, debido a que las 
personas en las culturas occidentales mueven sus ojos en una página de esta forma. En esta 
sección se deben proporcionar títulos e instrucciones que ayuden al usuario a teclear los da¬ 
tos correctos en el lugar correspondiente. La ayuda específica dependiendo del contexto 
también está disponible cuando el usuario hace clic con el botón derecho del ratón en la 
sección del cuerpo de la pantalla. 

La tercera sección de la pantalla corresponde a "los comentarios y las instrucciones". Es¬ 
ta sección podría desplegar un menú corto de comandos que le recuerdan al usuario ele- 
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mentos básicos, por ejemplo cómo cambiar páginas o funciones, guardar el archivo o termi¬ 
nar la entrada. La inclusión de dichos elementos puede hacer que los usuarios inexpertos se 
sientan infinitamente más seguros sobre su habilidad para operar la computadora. 

Otra forma de mantener la sencillez de la pantalla es usar la ayuda sensible al contex¬ 
to y otras ventanas desplegables. Los usuarios pueden minimizar o maximizar el tamaño 
de las ventanas conforme se requiera. De esta forma, los usuarios empiezan con una pan¬ 
talla sencilla y bien diseñada que pueden personalizar y controlar mediante el uso de 
ventanas múltiples. Los hipervínculos de un formulario completado en la Web cumplen 
un propósito similar. 


CÓMO MANTENER CONSISTENCIA EN LA PANTALLA 

El segundo lincamiento para el diseño adecuado de pantallas es mantener consistentes las 
pantallas. Si los usuarios están trabajando desde los formularios impresos, las pantallas de¬ 
ben seguir lo que se muestra en el papel. Las pantallas se pueden mantener consistentes al 
colocar información en la misma área cada vez que se accede una nueva pantalla. Tam¬ 
bién, la información relacionada lógicamente se debe agrupar de forma consistente: el 
nombre y la dirección van juntos, no el nombre y el código postal. Aunque la pantalla de¬ 
be tener un movimiento natural de un área a otra, la información no se debe pasar de un 
grupo a otro. Usted no querría el nombre y la dirección en un área y el código postal en 
otra. 

CÓMO FACILITAR EL MOVIMIENTO 

El tercer lineamiento para el diseño adecuado de pantallas es hacerlo fácil de mover de una 
página a otra. La regla de los tres clics dice que los usuarios deben poder obtener las páginas 
que necesitan con sólo tres clics del ratón o del teclado. Los formularios basados en la Web 
facilitan el movimiento con el uso de hipervínculos a otras páginas Web relevantes. Otro 
método común para el movimiento es que los usuarios tengan la sensación de que se están 
moviendo físicamente a una página nueva. Por lo menos hay tres formas en que esta ilusión 
de movimiento físico se desarrolla en las pantallas: 

1. Desplazamiento usando las flechas de las teclas de PgDn (Av Pág). 

2. Ventanas emergentes sensibles al contexto. 

3. Diálogo en pantalla. 

En la figura 12.7 se muestra un ejemplo de una ventana emergente sensible al contexto. 


CÓMO DISEÑAR UNA PANTALLA ATRACTIVA 

El cuarto lineamiento para el diseño adecuado de pantallas es crear una pantalla atractiva 
para el usuario. Si los usuarios ven atractivas las pantallas, probablemente sean más produc¬ 
tivos, necesiten menos vigilancia y cometan menos errores. También, algunos de los princi¬ 
pios de diseño usados para los formularios se aplican aquí, y algunos principios estéticos ya 
han aparecido en un contexto ligeramente diferente. 

Las pantallas deben atraer a los usuarios hacia ellos y deben atrapar su atención. Esta 
meta se realiza con el uso de un área bastante abierta que incluye los campos de entrada de 
datos de manera que la pantalla logre una apariencia atractiva. Nunca atestaría un formu¬ 
lario en papel; del mismo modo, nunca debe atestar una pantalla. Seguramente estará en 
una mejor situación si usa ventanas múltiples o hipervínculos que si amontona todo en una 
página. Al crear pantallas que a primera vista son fáciles de entender, atrae tanto a los usua¬ 
rios inexpertos como a los experimentados. 

Use flujos lógicos en el diseño de sus páginas desplegadas. Organice el material para 
aprovechar la forma en que trabajan las personas de manera que puedan desenvolverse con 
facilidad. También, divida de forma consistente la información en las tres secciones más pe¬ 
queñas detalladas anteriormente. 
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FIGURA i 2.7 

Pantalla para solicitar más 
detalles relacionados con los 
gastos de comida de un 
empleado (pantalla diseñada 
con FormFlow Filler de JetForm). 
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Si la pantalla es necesariamente compleja, el grosor de las líneas de separación entre 
las subcategorías puede variar para agregar distinciones más detalladas. La variedad ayuda 
a que el usuario vea rápidamente el propósito de la pantalla y qué elementos de datos se 
requieren. 

Con la llegada de las GUIs, es posible hacer pantallas de entrada de datos muy atracti¬ 
vas. Al usar color o cuadros sombreados y crear cuadros y flechas tridimensionales puede 
hacer formularios amigables y divertidos para el usuario. La figura 12.8 muestra un ejemplo 


FISURA 12.8 

Con el software FormFlow de 
JetForm es posible diseñar 
pantallas de entrada de datos 
atractivas que presenten efectos 
tridimensionales. 
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fuente son otra forma de hacer pantallas atractivas para los usuarios. Los diferentes estilos 
mejoran la diferenciación entre categorías. Por ejemplo, los estilos de fuente negrita y sans 
serif se pueden usar para denotar categorías principales y para dar a las pantallas una apa¬ 
riencia moderna. Las fuentes más grandes pueden indicar los títulos para los campos de en¬ 
trada de datos. 

Al considerar el uso de diferentes estilos y tamaños de fuente, pregúntese a sí mismo si 
realmente ayudan al usuario a entender y aprobar la pantalla. Si atraen la atención indebida 
al diseño de la pantalla o si sirven como una distracción, omítalos. Esté consciente que no 
todas las páginas Web se ven iguales en los diferentes navegadores. Pruebe sus formularios 
con una variedad de combinaciones para ver si las combinaciones de color resultantes serán 
agradables o desagradables para la mayoría de los usuarios. 


USO DE ICONOS EN EL DISEÑO DE PANTALLAS 

Los iconos son representaciones gráficas en pantalla que simbolizan las acciones de la compu¬ 
tadora y que los usuarios podrían seleccionar usando un ratón, teclado, lápiz óptico o palanca 
de juegos. Los iconos cumplen funciones similares a las palabras y se podrían reemplazar en 
muchos menús, debido a que su significado se entiende con mayor rapidez que las palabras. 
En la figura 12.9 se muestran los iconos diseñados para Microsoft Excel. 

Hay algunos lincamientos para el diseño de iconos eficaces. Las formas se deben reco¬ 
nocer con facilidad de manera que al usuario no se le exija dominar un vocabulario nuevo. 
La mayoría de usuarios actualmente conoce muchos iconos. El uso de iconos estándar puede 
aprovechar rápidamente este conocimiento común de sus significados. Un usuario podría 
señalar un archivero, "extraer" un icono de carpeta de archivo, "tomar" una parte del icono 
de papel y "tirarlo" en la papelera. Al usar los iconos estándar, diseñadores y usuarios aho¬ 
rran tiempo. 

Los iconos para una aplicación particular se deben limitar aproximadamente a 20 fi¬ 
guras reconocibles, de manera que el vocabulario del icono no sea abrumador y se pueda 
conseguir un esquema de codificación importante. Use los iconos de forma consistente en 
las aplicaciones donde aparecerán en conjunto para asegurar la continuidad y comprensibi¬ 
lidad. Por lo regular, los iconos son útiles si son significativos. 


DISEÑO DE LA INTERFAZ GRAFICA DE USUARIO 

Una interfaz gráfica de usuario (GUI) es la forma en que los usuarios interactúan con los 
sistemas operativos Windows y Macintosh. A esto también se le conoce como interfaz de 
apuntar y hacer clic. Los usuarios pueden usar un ratón para hacer clic en un objeto y arras¬ 
trarlo a una posición. La interfaz gráfica de usuario aprovecha las características adicionales 
en el diseño de pantallas tales como cuadros de texto, casillas de verificación, botones de 
opción, cuadros de listas y cuadros de listas desplegables, deslizadores y botones giratorios, 
mapas de imágenes y cuadros de diálogo con fichas. La figura 12.10 es una pantalla de en¬ 
trada de datos de Microsoft Access que muestra una variedad de controles GUI. 
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Cuadros de texto Un rectángulo representa un cuadro de texto, como se mencionó ante¬ 
riormente, y se usa para delinear la entrada de datos y los campos de pantalla. Se debe tener 
cuidado para asegurar que el cuadro de texto es lo suficientemente grande para acomodar 
todos los caracteres que se deben teclear. Cada cuadro de texto debe tener un título del 
lado izquierdo, que describe lo que se debe teclear o lo que se debe desplegar en el cuadro. 
Los datos de carácter se deben alinear a la izquierda y los datos numéricos a la derecha. 

Casillas de verificación En el ejemplo de los controles GUI, se usa una casilla de verifi¬ 
cación para indicar el nuevo cliente. Las casillas de verificación contienen una X o están 
vacías, de acuerdo a si el usuario seleccionó o no la opción; se usan para opciones no exclu- 
yentes en las cuales una o más de las opciones se puede activar. Una notación alternativa es 
usar un botón cuadrado con una marca de verificación (/) para indicar que la opción se ha 
seleccionado. Observe que el texto de la casilla de verificación, o etiqueta, normalmente se 
pone a la derecha de la casilla. Si hay más de una casilla de verificación, las etiquetas deben te¬ 
ner algún orden con respecto a dichas casillas, ya sea alfabético o con el elemento normalmen¬ 
te verificado en primer lugar de una lista. Si hay más de 10 casillas de verificación, agrúpe¬ 
las en un recuadro con borde. 

Botones de opción Un círculo, llamado botón de opción, se usa para seleccionar opciones 
excluyentes. Sólo se puede elegir una de varias opciones. Nuevamente las opciones se ponen 
a la derecha del botón, normalmente en alguna secuencia. Si hay una opción que se elige 
con frecuencia, normalmente aparece de forma predeterminada cuando la página se des¬ 
pliega por primera vez. Comúnmente hay un rectángulo, llamado grupo de opción, que en¬ 
cierra a los botones de opción. Si hay más de seis botones de opción, considere el uso de un 
cuadro de lista o de un cuadro de lista desplegable. 

Cuadros de lista y cuadros de lista desplegable Un cuadro de lista despliega varias opcio¬ 
nes que se podrían seleccionar con el ratón. Un cuadro de lista desplegable se usa cuando 
hay poco espacio en la página. Un rectángulo sencillo con una flecha que apunta hacia aba¬ 
jo localizada del lado derecho del rectángulo. Al seleccionar esta flecha se despliega el cua¬ 
dro de lista. Una vez que se ha seleccionado la opción, ésta se despliega en el rectángulo de 
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ye los valores. La figura 12.11 ilustra el uso de los deslizadores para cambiar la cantidad de 
rojo, verde y azul al seleccionar un color nuevo. Los botones giratorios también se usan pa¬ 
ra cambiar un valor continuo y se muestran a la derecha de los deslizadores. 

Mapas de imagen Los campos de mapa de imagen se usan para seleccionar valores dentro 
de una imagen. El usuario hace clic en un punto dentro de una imagen y las coordenadas 
x/y correspondientes se envían al programa. Los mapas de imagen se usan al crear páginas 
Web que contienen mapas con instrucciones para hacer clic en una cierta área para mostrar 
un mapa detallado de la región. 

Áreas de texto Un área de texto se usa para introducir una gran cantidad de texto. Estas 
áreas incluyen varias filas, columnas y barras de desplazamiento que permiten al usuario in¬ 
troducir y ver el texto que excede el tamaño del área del cuadro. Hay dos formas de manejar 
este texto. Una es evitar el uso del pase automático de palabras al siguiente renglón, obli¬ 
gando al usuario a presionar la tecla Enter para pasar a la siguiente línea; el texto se despla¬ 
zará a la derecha si excede el área de texto. La otra opción es permitir el pase automático de 
palabras a la siguiente línea sin necesidad de usar la tecla Enter. 

Cuadros de mensaje Estos se usan para mostrar advertencias y otros mensajes de retroali- 
mentación en un cuadro de diálogo, que con frecuencia aparecen sobre la pantalla. Estos 
cuadros de mensaje tienen formatos diferentes. Cada uno debe aparecer en una ventana 
rectangular y debe explicar claramente el mensaje. 

Botones de comando Un botón de comando desempeña una acción cuando el usuario lo 
selecciona con el ratón. Calcular el total, Agregar pedido y Aceptar son ejemplos. El texto 
se centra dentro del botón, el cual tiene una forma rectangular. Si hay una acción predeter¬ 
minada, el texto se encierra con una línea discontinua. El botón también se puede sombrear 
para indicar que es el predeterminado. Al presionar la tecla Enter se selecciona el botón pre¬ 
determinado. 


CUADROS DE DIALOGO CON FICHAS 

Estos son otra parte de las interfaces gráficas de usuario y otra forma para que los usuarios 
se organicen y accedan al material del sistema de manera eficaz. La figura 12.12 proporcio¬ 
na un ejemplo de cuadro de diálogo con fichas. Los lincamientos para diseñar los cuadros de 
diálogo con fichas incluyen: 

1. Crear una ficha para cada característica única (por ejemplo, una para seleccionar el co¬ 
lor y otra para seleccionar texto, fondo, cuadrícula u otras características de fuente]. 
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2. Colocar las fichas usadas con mayor frecuencia al frente y desplegarlas primero. 

3. Considerar la inclusión de tres botones básicos en su diseño: Aceptar, Cancelar y Ayuda. 

Como se puede ver en la figura 12.13, Microsoft Office 2000 introdujo un tipo de cua¬ 
dro de diálogo que tiene la apariencia y comportamiento de una página Web. Del lado iz¬ 
quierdo hay botones llamados sitios. Estos botones están hipervinculados a los elementos 
que el usuario querría acceder con frecuencia. Los sitios predeterminados son "Historial", el 
cual despliega una lista de los archivos usados recientemente; "Mis Documentos", que es la 
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SOLO ES UNA MASCARA 


Al considerar la actualización del -diseño del sitio Web de comercio 
electrónico Marathón Vltamin Shops, Bill Berry,e¡ dueño, comprendió que 
sus clientes eran muy diversos.?; I " 

"Hemos trabajado duro para atraermuchos tipos diferentes de clientes. 
Hasta el momento, estamos teniendo éxito. Vienen personas con muchos 
intereses diferentes. Me he encontrado a entusiastas délos deportes que 
quieren las vitaminas de alta energía para-reforzar su fuerza. Otros 
clientes quieren perder peso con la ayuda de suplementos vitamínicos; 
Algunos de nuestros.clientes se preocupan por su salud y creen qué una , 
vitamina al día mantiene al doctor lejos. Algunos se aterran aléstilo de 
vida tílppie que cultivaron en los años setenta y necesitan sólo suple¬ 
mentos Orgánicos; A propósito la tienda está lista, usted puede ver que 
nosotros estamosísegmehtando el espacio para que cada tipo de cliente 
se sienta en su mundo; Sin enlbárgo, es; difícil;traducir eso a la Web;'' 

Bill voltea haciaúno de sus empleados, JlnSingh, y le pregunta: 
"¿Hay algo que podamos hácer para:transformar'.el catálogo en línea pa¬ 
ra que atraiga a el lentes diferentes? Y'¿qué hay sobre ser sensible a las 
sensibilidades de personas diferentes que visitan.el sitio?" . : . L 

; Jin, que es unentusiastadei Webcastdelnternet A dlce¡ A lengqlasp-, 
iución",conforme voltea hacia sucomputadorayabresu WindowsMedia 
Player. "En ío personal, me gusta entrar en un estado mental que se 
ajusta a la música o vídeos que estoy experimentando en la Web." 


Jin muestra a Bill ejemplos de algunas máscaras en la pantalla. La 
figura 12.C4 muestra una serie de máscaras que se pueden usar con el 
Microsoft Windows Media Player. 

Jiñ prosigue: "Las máscaras me permiten personalizar la apariencia 
de mi Reproductor de Medios. Cuando toco canciones antiguas escojo:la 
máscara oxidada. Cuando toco algo New Age, prefiero la máscara con un 
arcoiris, y así sucesivamente". 

Viendo la pantalla Bill exclama: "¡Me parece que tienes un punto!, 
¿Cómd dices que se llama eso?" 

Jin sonríe y explica: "Se llaman máscaras, pero son sólo patrones di¬ 
vertidos que los usuarios pueden sobreponer a cualquier cosa que estén 
viendo. Tengo la visión qué una página Web puede tomar una apariencia 
totalmente nueva dependiendo de las preferencias del usuario por algún 
. tipo particular de máscara"; 

-Con baséén su percepción de los diferentes tipos de clientes que Ma¬ 
rathón quisiera atraer a su sitio Web, diseñe, dibuje y describa una serle, 
de máscaras que considera apropiadas para los propósitos de la empre¬ 
sa. Explique cómo es que el Incluir máscaras controladas por el usuario 
: en un sitio Web puede favorecer los objetivos de diseño del analista en lo 
que respecta a atractivo y facilidad para Introducir datos. 
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ubicación predeterminada para guardar archivos; "Escritorio"; "Favoritos", los cuales son los 
sitios Web que el usuario marcó en su navegador, y "Carpetas Web", que son los sitios Web 
que el usuario construyó. Estos sitios se pueden personalizar usando software especial tal 
como el WOPR Placebar Customizer de manera que los usuarios puedan construir sus pro¬ 
pios botones de acceso directo. 

El directorio actual se encuentra en el centro del cuadro de diálogo; cualesquier ar¬ 
chivos o carpetas que estén en dicho directorio se despliegan en el cuadro de diálogo. El 
cuadro que está a la derecha se llama área de visualización. Al hacer clic en un icono, un 
usuario puede ver los detalles acerca de los archivos, las propiedades de un solo archivo o una 
vista previa del archivo actual. En este ejemplo, se visualiza previamente el documento 
"OASIS June 2000.pub" de Microsoft Publisher. 

Este cuadro de diálogo también tiene un cuadro desplegable para una navegación fácil 
e iconos que permiten al usuario crear nuevas carpetas y navegar o buscar en Web. 

USO DE COLOR EN EL DISEÑO DE PANTALLAS 

El color es una forma atractiva y consolidada para facilitar la entrada de datos a la computado¬ 
ra. El uso apropiado de color en las pantallas desplegadas le permite contrastar el color de primer 
plano y el de fondo, resaltar los campos importantes en los formularios, destacar los errores, re¬ 
saltar la entrada de código especial y poner atención a muchos otros atributos especiales. 

Se deben usar colores muy contrastantes para desplegar el color de primer plano y el de 
fondo para que los usuarios puedan comprender con rapidez lo que se presenta. El color 
de fondo afectará la percepción del color de primer plano. Por ejemplo, el verde oscuro po¬ 
dría parecer un color diferente si se quita de un fondo blanco y se pone en uno amarillo. 

Las cinco combinaciones más legibles de un texto en primer plano sobre un fondo son 
[empezando con la combinación más legible]: 

1. Negro sobre amarillo. 

2. Verde sobre blanco. 

3. Azul sobre blanco. 

4. Blanco sobre azul. 

5. Amarillo sobre negro. 

Los menos legibles son rojo sobre verde y azul sobre rojo. Como se puede deducir de estas 
combinaciones de color de primer plano y de fondo, se deben usar colores brillantes para el 
primer plano, con colores menos luminosos para el fondo. Los colores que contrastan fuer¬ 
temente se deben asignar primero para los campos que se deben diferenciar; después se 
pueden asignar otros colores. 

Use el color para resaltar los campos importantes en las pantallas. Los campos que son 
importantes se pueden colorear de forma diferente que los demás. Tenga en cuenta las nor¬ 
mas culturales. Normalmente el rojo significa peligro, pero "en números rojos" también sig¬ 
nifica que una compañía pierde dinero. El verde significa "siga" y es un color seguro en los 
países occidentales. 

Como con cualquier mejora, los diseñadores necesitan cuestionar el valor agregado de 
usar color. El uso de color se puede exagerar; una regla heurística útil es no más de cuatro 
colores para usuarios principiantes y sólo hasta siete para experimentados. Los colores irre¬ 
levantes distraen a los usuarios y disminuyen su desempeño. Sin embargo, en muchos casos 
se ha mostrado que el color facilita el uso de formas muy específicas. El color se debe con¬ 
siderar una forma importante de contrastar primeros planos y fondos, resaltar los campos 
importantes, señalar los errores y permitir codificación especial de entrada. 


DISEÑO DE PÁGINAS DE INTRANET E INTERNET 

En el capítulo 11 se discutieron los elementos básicos del diseño de sitios Web. Hay más su¬ 
gerencias sobre el diseño de un adecuado formulario para contestar en Internet o una Intra¬ 
net que se deben observar ahora que ya conoce algunos de los aspectos elementales del di¬ 
seño de formularios y pantallas de entrada. La figura 12.14 muestra una página de pedido 
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La pantalla de pedido del sitio 
Web de Nordstrom 
(www.nordstrom.com) es un 
buen ejemplo de cómo diseñar 
un formularlo de entrada que es 
claro, fácil dé usar y funcional. 


con un formulario que presenta muchos elementos del diseño adecuado para Web. Los li¬ 
ncamientos incluyen lo siguiente: 

1. Proporcione instrucciones claras, ya que los usuarios Web podrían no estar familiariza¬ 
dos con la terminología de la computadora. 

2. Demuestre una secuencia de entrada lógica para los formularios, sobre todo porque los 
usuarios podrían tener que desplazarse a un área de la página que al principio puede no 
ser visible. 

3. Use una variedad de cuadros de texto, botones de comando, menús desplegables, casi¬ 
llas de verificación y botones de opción para realizar funciones específicas y crear inte¬ 
rés en el formulario. 

4. Proporcione un cuadro de texto desplazable si no sabe con certeza cuánto espacio nece¬ 
sitarán los usuarios para responder a una pregunta o qué lenguaje, estructura o forma uti¬ 
lizarán los usuarios para introducir datos. 

5. Prepare dos botones básicos en cada formulario que se contestará en la Web: Enviar y 
Limpiar contenido. 

6. Si el formulario es largo y los usuarios se deben desplazar en forma excesiva, divida el 
formulario en varios formularios simples en páginas separadas. 

7. Cree una pantalla de retroalimentación que indique que se rechaza el envío de un 
formulario a menos que los campos obligatorios estén completados correctamente. La 
pantalla de formulario devuelta puede proporcionar comentarios detallados al usuario 
en un color diferente. El rojo es apropiado aquí. Por ejemplo, podría ser necesario que 
un usuario complete el campo de país, o que indique un número de tarjeta de crédito 
si ese tipo de pago se ha activado. 

Las aplicaciones de comercio electrónico implican más que sólo un diseño adecuado de 
sitios Web. Los clientes necesitan sentirse seguros de que compran la cantidad correcta, que 
consiguen el precio correcto y de que el costo total de una compra de Internet, incluyendo 
los gastos de envío, es lo que esperan. La forma más común de establecer esta confianza es 
usar la metáfora de un carrito o bolsa de compras. La figura 12.15 muestra los contenidos 
de un carrito de compras para un cliente que hace una compra. Una característica impor¬ 
tante del carrito de compras es que el cliente puede revisar la cantidad del artículo pedido 
o puede quitar el artículo por completo. 
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El sitio Web de Nordstrom 
(www.nordstrom.com) es un 
buen ejemplo de carrito de 
compras. Nordstrom lo llama 
bolsa de compras {shopping 
bag). 
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Las aplicaciones de comercio electrónico agregan más demandas al analista quien debe 
diseñar los sitios Web para cumplir varios objetivos del negocio, incluyendo la publicación 
de la misión corporativa y de los valores con respecto a la confidencialidad, privacidad y de¬ 
volución de productos; el procesamiento eficaz de transacciones; y establecer buenas rela¬ 
ciones con el cliente. 


RESUMEN 

Este capítulo ha tratado elementos de diseño de entrada para formularios, pantallas y 
formularios para contestar en la Web. La entrada bien diseñada debe lograr los objetivos de 
efectividad, precisión, facilidad de uso, simplicidad, consistencia y atractivo. El conocimien¬ 
to de muchos elementos de diseño diferentes permitirá al analista de sistemas alcanzar es¬ 
tos objetivos. 

Los cuatro lincamientos para los formularios de entrada bien diseñados son los siguientes: 

1. Los formularios deben ser fáciles de completar. 

2. Los formularios deben cumplir el propósito para el cual se diseñan. 

3. Los formularios se deben diseñar para asegurar precisión en su llenado. 

4. Los formularios deben ser atractivos. 

El diseño de formularios útiles, pantallas y formularios para contestar en la Web se traslapa de 
muchas formas importantes, pero hay algunas distinciones. Las pantallas muestran un cursor 
que continuamente orienta al usuario. Con frecuencia las pantallas proporcionan asistencia 
con la entrada, mientras que con la excepción de instrucciones impresas previamente, podría 
ser difícil obtener asistencia adicional con un formulario en papel. Los documentos basados 
en Web tienen funciones adicionales, tales como hipervínculos integrados, funciones de ayu¬ 
da sensible al contexto y formularios de retroalimentación, para corregir la entrada antes del 
envío final. Se pueden agregar máscaras como una opción para personalizar un sitio Web. 

Los cuatro lincamientos para las pantallas bien diseñadas son como sigue: 

1. Las pantallas se deben mantener simples. 

2. Las pantallas deben ser consistentes en la presentación. 
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"¿No es la primavera la estación más bonita aquí? El arquitecto realmente capturó la esen¬ 
cia del paisaje, ¿no es verdad? Usted no puede ir por el edificio sin admirar otra vista mara¬ 
villosa por esas ventanas. Cuando Snowden regresó, vio sus pantallas de salida. Las buenas 
noticias son que él piensa que funcionan. El proyecto está floreciendo, como las plantas y 
árboles. Cuando Snowden vuelva de Finlandia, ¿tendrá usted algunas pantallas de entrada 
listas para demostración? El no quiere que el proyecto se detenga sólo porque él está fue¬ 
ra del país. A propósito, el viaje, de Singapur tuvo mucho éxito. Quizá MRE algún día será 
una empresa global." , 
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PREGUNTAS DE HYPERCASE 

1. Usando una hoja de diseño o software como el FormFlow de JetForm, diseñe un pro¬ 
totipo que capture la información del cliente para la Unidad de Capacitación. 

2. Pruebe su formulario con tres compañeros de clase haciendo que cada uno lo conteste. 
Pídales una crítica escrita del formulario. 

3. Rediseñe su formulario de entrada para reflejar los comentarios de sus compañeros de 
clase. 

4. Usando una hoja de diseño o una herramienta CASE, diseñe un formulario de pantalla 
prototipo que capture la información del cliente para la Unidad de Capacitación. 

5. Pruebe su pantalla de entrada con tres compañeros de clase haciendo que cada uno de 
ellos la utilice. Pídales una crítica escrita de su diseño de pantalla. 

6. Rediseñe la pantalla de entrada basándose en los comentarios que reciba. En un párra¬ 
fo, explique cómo ha manejado cada comentario. 
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3. El diseño debe facilitar el movimiento entre las páginas. 

4. Las pantallas deben ser atractivas. 

Muchos elementos de diseño diferentes permiten al analista de sistemas seguir estos linca¬ 
mientos. 

El flujo apropiado de formularios impresos, pantallas y formularios para contestar en la 
Web es importante. Los formularios deben agrupar la información lógicamente en siete ca¬ 
tegorías, y las pantallas se deben dividir en tres secciones principales. Los títulos en formu¬ 
larios y pantallas pueden variar, al igual que los tipos de fuente y los grosores de las líneas 
que dividen subcategorías de información. Los formularios de múltiples partes son otra for¬ 
ma de asegurar que los formularios alcancen sus objetivos. Los diseñadores pueden usar 
ventanas, sugerencias, cuadros de diálogo y valores predeterminados en pantalla para asegu¬ 
rar la efectividad del diseño. 

Las pantallas se pueden diseñar usando varias herramientas CASE. También se pueden 
usar iconos, color e interfaces gráficas de usuario para reforzar el entendimiento del usuario 
de las pantallas de entrada. 

Los formularios para contestar en la Web se deben construir teniendo en cuenta los si¬ 
guientes siete lincamientos así como también los del capítulo 11: 

1. Proporcione instrucciones claras. 

2. Demuestre una secuencia de entrada lógica para los formularios. 

3. Use una variedad de cuadros de texto, botones de comando, menús desplegables, casi¬ 
llas de verificación y botones de opción. 

4. Proporcione un cuadro de texto desplegable si no sabe con exactitud cuánto espacio 
necesitarán los usuarios para contestar una pregunta. 

5. Prepare dos botones básicos en cada formulario que se contestará en la Web: Enviar y 
Limpiar contenido. 

6. Si el formulario es largo y los usuarios se deben desplazar excesivamente, divida el 
formulario en varios formularios más sencillos en páginas separadas. 

7. Cree una pantalla de retroalimentación que indique que se rechaza el envío de un 
formulario a menos que los campos obligatorios estén completados correctamente. 


PALABRAS Y FRASES CLAVE 


botón de comando 
botón de opción 
botón giratorio 
casilla de verificación 
color en pantalla 

combinaciones de color de pantalla 

control de formularios de negocios 

cuadro de diálogo con fichas 

cuadro de lista 

cuadro de lista desplegable 

cuadro de mensaje 

cuadro de texto 

cursor 

cursor intermitente 

deslizadores 

diálogo en pantalla 

facilitar el movimiento en páginas 


flujo del formulario 
formulario especializado 
formulario para contestar en 
Internet/intranet 
icono en pantalla 
mapa de imagen 
máscaras 

siete secciones de un formulario 

sugerencia 

tiempo de respuesta 

título con casillas horizontales 

título con casillas verticales 

título con línea 

título de cuadro 

título de tabla 

tres secciones de una pantalla 
vídeo inverso 


PREGUNTAS DE REPASO 

1. ¿Cuáles son los objetivos del diseño de los formularios de entrada impresos, pantallas 
de entrada o formularios para contestar en la Web? 

2. Mencione los cuatro lincamientos para el diseño adecuado de formularios. 
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3. ¿Cuál es el flujo apropiado de formularios? 

4. ¿Cuáles son las siete secciones de un buen formulario? 

5. Mencione cuatro tipos de títulos usados en los formularios. 

6. ¿Qué es un formulario especializado? ¿Cuáles son algunas desventajas de usar formu¬ 
larios especializados? 

7. ¿Cuáles son las funciones básicas involucradas en el control de formularios? 

8. Mencione los cuatro lincamientos para el diseño adecuado de pantallas. 

9. ¿Cuáles son las tres secciones útiles para simplificar una pantalla? 

10. ¿Cuáles son las ventajas de usar ventanas en pantallas? 

11. ¿Cuáles son las desventajas de usar ventanas en pantallas? 

12. Mencione dos formas de mantener consistentes las pantallas desplegadas. 

13. Proporcione tres formas para facilitar el movimiento entre las páginas de un formulario 
en pantalla. 

14. Mencione cuatro elementos del diseño de la interfaz gráfica. Junto a cada uno, describa 
cuándo seria correcto incorporar cada uno de ellos en un diseño de pantalla o en un 
formulario para contestar en la Web. 

15. Defina el significado de iconos desplegados en pantalla. ¿Normalmente cuándo son úti¬ 
les los iconos para el diseño de pantallas? ¿Y para el diseño de formularios para contes¬ 
tar en la Web? 

16. Mencione las cinco combinaciones más legibles de color de primer plano y de fondo 
para el uso en pantallas. 

17. Defina el significado del término máscaras cuando se usa en el diseño Web. 

18. ¿Cuáles son los tres botones que se deben incluir con un cuadro de diálogo de control 
con fichas? 

19. ¿Cuáles son las cuatro situaciones en que el color podría ser útil para el diseño de pan¬ 
tallas y de formularios para contestar en la Web? 

20. Mencione siete lincamientos del diseño para un formulario para contestar en la Web. 


PROBLEMAS 

1. Aquí hay títulos que se usan en un formulario de censo estatal: 
Nombre 


Ocupación 


Dirección 


Código postal 


Número de personas en la casa 


Edad del jefe de la casa 

a. Escriba nuevamente los títulos para que la oficina de censos estatales pueda cap¬ 
turar la misma información solicitada en el formulario viejo sin confundir a los 
encuestados. 

b. Rediseñe el formulario para que muestre el flujo apropiado. [Sugerencia: asegúrese 
de proporcionar un acceso y una sección de identificación para que la información 
se pueda almacenar en las computadoras del estado.] 

c. Rediseñe el formulario de modo que lo puedan contestar las personas que visiten 
el sitio Web del estado. ¿Qué cambios fueron necesarios para pasar de un formu¬ 
lario impreso a uno que se enviará electrónicamente? 

2. El Elkhorn College necesita mantener un buen registro de los libros prestados de su Bi¬ 
blioteca Buck Memorial. 

a. Diseñe y bosqueje un formulario impreso de 4 X A" x Sf>" para prestar los libros de 
la biblioteca. Etiquete las siete secciones de un formulario que incluyó. 
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b. Diseñe y bosqueje una representación de una pantalla para lograr lo mismo. Eti¬ 
quete las tres secciones de una pantalla que incluyó. 

3. Consulte la figura 12.9 que muestra los iconos de Microsoft Excel e intente explicar el 
significado de cada icono. Proponga nuevos iconos si los actuales son confusos. 

4. Eche un vistazo a la figura 12.EX1. Estos iconos son de Freelance Graphics. Intente 
averiguar lo que significa cada icono. ¿La bombilla tiene, el mismo significado que la 
bombilla de la aplicación de Excel en el problema 3? Explique. Sugiera otros iconos 
mejores. 

5. Speedy Spuds es un restaurante de comida rápida que ofrece todos los tipos de papas. 
El gerente tiene una regla de 30 segundos para servir a los clientes. Los despachadores de 
mostrador dicen que podrían cumplir esa regla si se simplificara el formulario que deben 
completar y dar al personal de la cocina. La información del formulario completado 
se teclea en el sistema de cómputo al final del día, cuando el capturista de datos nece¬ 
sita teclear el tipo de papa comprado, adornos adicionales comprados, cantidad y precio 
cobrado. El formulario actual es difícil de analizar y completar con rapidez por los des¬ 
pachadores. 

a. Diseñe y bosqueje un formulario (usted escoja el tamaño, pero sea sensato) que liste 
las papas y adornos posibles de una forma que sea fácil de entender para los despa¬ 
chadores de mostrador, el personal de la cocina, y que también se pueda usar como 
entrada para el sistema de inventario/pedido que conecta mediante una extranet a 
Speedy Spuds y a los cultivadores de papas de Idaho. [Sugerencia: recuerde obser¬ 
var todos los lincamientos para el diseño adecuado de formulario.} 

b. Diseñe y bosqueje una representación de una pantalla que puedan usar los despa¬ 
chadores y empleados para completar la información capturada en el formulario. 

c. Diseñe una pantalla desplegada basada la pantalla que diseñó en el problema 5b. 
Ahora, debe funcionar como una pantalla que muestra lo que prepara un miem¬ 
bro del personal de la cocina para cada pedido de Spud. Mencione tres cambios 
que le tuvo que hacer a la pantalla existente para que funcione como una pantalla 
de salida. 

6. Sherry Meats, comerciante de carne regional al mayoreo y menudeo, necesita recopilar 
información actualizada acerca de cuánto de cada producto de carne tiene en cada al¬ 
macén. Después usará esa información para fijar las entregas de su almacén central. Ac¬ 
tualmente, los clientes introducen en el almacén un formulario completo detallado que 
especifica sus pedidos individuales. El formulario lista más de 150 artículos; incluye 
carne y productos de carne disponibles en diferentes cantidades. Al final del día, entre 
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250 y 400 pedidos de cliente se tabulan y deducen del inventario del almacén. Enton¬ 
ces el oficinista de cada almacén telefonea en un pedido para el día siguiente. Los em¬ 
pleados del almacén tienen problemas al tabular las ventas debido a que los clientes 
con frecuencia cometen errores al completar sus formularios. 

a. No es posible que un solo oficinista en cada almacén pueda completar todos los 
pedidos de cliente. Cambie el formulario (3W x 6 A" horizontal o vertical) y dibú¬ 
jelo para que al cliente se le facilite completarlo correctamente y para que el ofici¬ 
nista lo tabule. 

b. Diseñe y bosqueje un formulario especializado del mismo tamaño, que satisfaga las 
necesidades de los clientes, oficinistas y almacenistas de Sherry. 

c. Diseñe y bosqueje dos formularios diferentes del mismo tamaño que satisfagan los 
propósitos del problema 6b, debido a que Sherry transporta productos de pollería 
y carne de res. (Sugerencia: piense en formas de hacer formularios más fáciles de 
distinguir visualmente.) 

d. Diseñe un formulario para completar en pantalla. Cuando un cliente envíe un pe¬ 
dido, es introducido en el sistema de inventario de Sherry por la persona que des¬ 
pacha a los clientes en el mostrador. Esta información se capturará y se enviará a la 
computadora del almacén central para ayudar a controlar el inventario. 

e. En un párrafo, describa las desventajas de tener muchas personas diferentes en di¬ 
ferentes ubicaciones que introducen datos. En un párrafo, mencione los pasos que 
puede seguir como diseñador de manera que se diseñe el formulario para asegurar 
la exactitud de entrada. 

7. R. George, una tienda de ropa de moda que también tiene un negocio de ventas por co¬ 
rreo, le gustaría mantener un registro de los clientes que entran en la tienda para exten¬ 
der su lista de correos de clientes. 

a. Diseñe y bosqueje un formulario sencillo que se pueda imprimir en taijetas de 3" x 
5" y se pueda dar a clientes en el almacén para completar. (Sugerencia: el formu¬ 
lario debe ser estéticamente atractivo para alentar a la clientela selecta de R. Geor¬ 
ge que los complete.) 

b. Diseñe y bosqueje una representación de una pantalla que capture la información 
de los clientes de las tarjetas del problema 7a. 

c. Diseñe y bosqueje un cuadro de diálogo con fichas que pueda usarse con la panta¬ 
lla del problema 7b, uno que permita una comparación entre la información del 
cliente en la tienda y una lista de clientes que mantienen tarjetas de crédito de R. 
George. 

d. Diseñe y bosqueje un segundo cuadro de diálogo con fichas que compare a clien¬ 
tes del almacén con los clientes de ventas por correo. 

e. El dueño lo está considerando para que le ayude a establecer un sitio de comercio 
electrónico. Diseñe un formulario basado en Web para capturar la información del 
visitante al sitio Web. En un párrafo, explique cómo diferirá del formulario impreso. 

8. La figura 12.EX2 muestra los iconos del administrador de información personal (PIM) 
llamado Organizer. Vea si puede deducir lo que significa cada icono. ¿Por qué cree que 
es importante el diseño adecuado de iconos? En un párrafo explique por qué cree (o no 
cree) que estos iconos se ajustan a los principios de diseño adecuados. 

















9. Diseñe un sistema de iconos desplegados en pantalla con formas prontamente reconoci¬ 
bles que permitan a ejecutivos de cuenta de las casas de bolsa determinar, a primera vis¬ 
ta, qué acciones (si hay] se necesitan realizar en la cuenta de un cliente. [Sugerencia: use 
una codificación de color así como también los iconos para facilitar la identificación rá¬ 
pida de condiciones extremas.} 

a. Diseñe y bosqueje iconos que corresponden a lo siguiente: 

i. Transacción completada el mismo día. 

ii. La cuenta se debe actualizar, 

ni. El cliente ha solicitado información, 

iv. Cuenta en error. 

v. Cuenta inactiva durante dos meses, 

vi. Cuenta cerrada. 

b. Recientemente, una prometedora casa de bolsa de descuento expresó un interés en 
desarrollar su propio software de administración de portafolios de inversiones ba¬ 
sado en la Web que los clientes podrían usar en su casa desde sus PCs para hacer 
compras, obtener cotizaciones actuales en tiempo real, etc. Diseñe dos pantallas de 
entrada para facilitar la entrada de datos al cliente. La primera pantalla debe per¬ 
mitir a los usuarios registrar los símbolos de las acciones que necesitan seguir en 
forma diaria. La segunda pantalla debe permitir al cliente usar un sistema basado 
en iconos para diseñar un informe personalizado que muestre las tendencias del 
precio de las acciones en una variedad de gráficos o texto. 

c. Sugiera otras dos pantallas de entrada que se deben incluir en este nuevo software 
de administración de portafolios de inversiones. 

10. My Belle Cosmetics es un negocio grande que tiene ventas muy por encima de cual¬ 
quier otra empresa regional de cosméticos. Como organización, es muy sensible al co¬ 
lor, porque introduce nuevas líneas de colores en sus productos durante otoño y prima¬ 
vera. Actualmente la compañía ha empezado a usar la tecnología para mostrar 
electrónicamente cómo se verían los clientes que visitan las tiendas con diferentes som¬ 
bras sin requerir que se apliquen los cosméticos. 

a. Diseñe y bosqueje una representación de una pantalla desplegada que puedan 
usar los empleados de ventas en un mostrador para mostrar a un cliente, con rapi¬ 
dez y exactitud, diferentes tonos de lápiz de labios y maquillaje. La información 
solicitada al cliente debe ser el color de su cabello, el color de su ropa favorita 
y el tipo de iluminación que prefiere (fluorescente, incandescente, al aire libre, 
etcétera). 

b. Diseñe y bosqueje una representación de una pantalla que sea equivalente a una 
del problema 10a pero que demuestre vivamente a tomadores de decisiones en My 
Belle cómo el color mejora el entendimiento de la pantalla. 

c. Uno de los afiliados que My Belle tiene en Web es una cadena grande de tiendas de 
departamentos. En un párrafo, describa cómo se puede alterar la pantalla desplegada 
del problema 10a para que un individuo pueda usarlo y My Belle pueda ponerlo 
en el sitio de comercio electrónico del almacén grande para atraer a clientes. 

11. La Home Finders Realty Corporation se especializa en buscar casas para probables 
compradores. La información de la casa se almacena en una base de datos y se debe 
mostrar en una pantalla desplegada de consulta. Diseñe una interfaz de GUI, para una 
pantalla basada en la Web para introducir los siguientes campos de datos, los cuales se 
usan para seleccionar y desplegar los criterios de búsqueda de casas. Tenga presente las 
características disponibles para una pantalla de GUI. Los elementos de diseño (los cua¬ 
les no están en una secuencia particular) son como sigue: 

a. Tamaño mínimo (en pies cuadrados). 

b. Tamaño máximo (en pies cuadrados, opcional). 

c. Número mínimo de alcobas. 

d. Número mínimo de baños. 

e. Tamaño de la cochera (número de carros, opcional). 

f. Distrito escolar (para cada área hay disponible un número limitado de distritos 
escolares). 


1432 


lili:: 


ASPECTOS ESENCIALES DEL DISEÑO 





g. Piscina (sí/no, opcional], 

h. Ubicación (ciudad, suburbio o rural), 

i. Chimenea (sí/no, opcional), 

j. Ahorro de energía (sí/no). 

Además, describa los hipervínculos necesarios para lograr este tipo de interacción. 

12. Diseñe, en tarjetas de índices, un cuadro de diálogo con fichas para cambiar el desplie¬ 
gue de una base de datos. Use una tarjeta para cada ficha. Asegúrese de agrupar cada fi¬ 
cha por función. 

a. Cambie el color de fondo. 

b. Cambie la fuente. 

c. Cambie el borde del objeto a una vista resaltada. 

d. Establezca el color de primer plano. 

e. Cambie el borde del objeto a una vista hundida. 

f. Establezca color de borde. 

g. Cambie el tamaño de fuente, 

h. Establezca el texto a negrita. 

i. Cambie el borde del objeto a una vista plana. 

j. Establezca el texto a subrayado. 

k. Cambie el color de fondo del objeto. 

13. Diseñe una página Web de bienvenida para la Home Finders Realty Corporation crea¬ 
da en el problema 11. 

14. La cadena hotelera TowerWood, con cinco años de antigüedad, necesita ayuda para di¬ 
señar su sitio Web. La compañía tiene propiedades en todas las grandes comunidades 
turísticas de Estados Unidos tales como Orlando, Florida (cerca de Disney World); 
Maui, Hawaii; Anaheim, California (cerca de Disneyland); Las Vegas, Nevada; y Nue¬ 
va Orleans, Louisiana. Sus propiedades ofrecen una variedad de cuartos en todas estas 
ubicaciones. 

a. En un párrafo, discuta cómo puede usar la compañía máscaras en su sitio Web pa¬ 
ra atraer diferentes tipos de clientela, incluyendo familias con niños pequeños, 
parejas jóvenes en su luna de miel, parejas jubiladas que quieren un viaje económi¬ 
co y viajeros de negocios que necesitan servicios comerciales. 

b. Diseñe y bosqueje una serie de máscaras que atraerían a los tipos diferentes de 
clientela del hotel listados en el problema 14a. [Sugerencia: use un paquete de grá¬ 
ficos o un programa de dibujo que le ayude a diseñar las máscaras.) 

c. Agregue un grupo de usuarios potenciales del sitio Web para la cadena hotelera To¬ 
werWood que no hayan sido mencionados en el problema 14a y diseñe y bosqueje 
máscaras adicionales para ellos. Después cree una tabla que haga coincidir cada 
grupo de cliente con una máscara particular que haya diseñado. 


PROYECTOS DE GRUPO 


1. MaverickTransport está considerando actualizar sus pantallas de entrada. Con su equipo, 
genere ideas acerca de lo que debe aparecer en las pantallas de entrada de operadores 
de computadora que están capturando los datos de las entregas conforme se aceptan las 
cargas. Los campos incluirán fecha de entrega, contenidos, peso, requerimientos espe¬ 
ciales (por ejemplo, si los contenidos son perecederos), etcétera. 

2. Cada miembro del equipo debe diseñar una pantalla de entrada apropiada mediante 
una herramienta CASE o papel y lápiz. Comparta sus resultados con los miembros de 
su equipo. 

3. Haga una lista de otras pantallas de entrada que debe desarrollar MaverickTransport. 
Recuerde incluir pantallas de despachador así como también pantallas que deban 
acceder los clientes y controladores. Indique cuáles deben ser pantallas de PC y cuáles 
pantallas en dispositivos portátiles inalámbricos. 

4. Diseñe una pantalla basada en la Web que permita a clientes de Maverick Transport 
seguir el progreso de un embarque. Realice una lluvia de ideas con los miembros de su 
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equipo para listar los elementos, o realice una entrevista a una compañía de transpor¬ 
te local para conocer sus requerimientos. Mencione qué hipervínculos serán esencia¬ 
les. ¿Cómo controlará el acceso para que los clientes puedan registrar sólo sus propios 
embarques? 


BIBLIOGRAFÍA SELECCIONADA 

Dahlboom, B. y L. Mathiassen, Computers in Context, Cambridge, MA: NCC Blackwell, 
1993. 

Ivés, B., "Graphical User Interfaces for Business Information Systems", MIS Quarterly 
(Special Issue), diciembre de 1982, pp. 15-48. 

Reisner, R, "Human Factors Studies of Data Base Query Languages: A Survey and 
Assessment", Computing Surueys, vol. 4, núm. 1, 1981. 


ASPECTOS ESENCIALES DEL DISEÑO 






ALLEN SCHMIDT, JULIE E. KENDALL Y KENNETH E. KENDALL 

CREACIÓN DE PANTALLAS Y FORMULARIOS 



Al reunir información sobre el diseño de la salida y revisar su progreso. Chip y Anna pasan 
a la siguiente etapa, el diseño de la entrada. "Los formularios y las pantallas se deben diseñar 
con el propósito de capturar con facilidad y precisión la información de entrada", afirma 
Anna. 

Chip contesta: "Se debe poner especial atención en la creación de pantallas de entrada 
fáciles de usar y que requieran una entrada mínima del operador". 

Chip carga Visible Analyst y analiza el Diagrama 0. "Tal vez el primer formulario que 
debemos crear es el NEW COMPUTER RECORD, que fluye desde el SHIPPING/RECEI- 
VING DEPARTMENT del proceso 2, ADD NEW COMPUTER." Chip hace doble che en 
el flujo de datos que representa el formulario para que aparezca el registro del depósito. Su 
área Composition contiene una estructura de datos denominada NEW COMPUTER 
FORM RECORD. "Decidí crear una estructura separada para el formulario, porque los ele¬ 
mentos se utilizan tanto en el formulario como en la pantalla correspondiente", reflexiona 
Chip. Hace clic en el área y en el botón Jump. Los elementos del formulario se incluyen en 
el área Composition de la estructura. El área Notes contiene información acerca de los cam¬ 
pos que se deben implementar como listas desplegables y casillas de verificación. 

Chip empieza a trabajar en el diseño del formulario. Lo divide en zonas para agrupar 
los elementos que tienen una relación lógica, de tal manera que permitan al usuario contes¬ 
tar con facilidad el formulario. Puesto que ya se había aprobado un prototipo de la pantalla 
de entrada de datos, la tarea de diseñar el formulario se simplificó de manera considerable. 

Chip programa una reunión con Dot para revisar el formulario. Ella observa pensati¬ 
vamente el documento durante algunos minutos y comenta: "Luce bastante bien. Veo que 
tomaste en cuenta nuestro punto de vista al diseñar el formulario. El único cambio que te 
sugiero es que separes la información inicial que tenemos al recibir la computadora, de los 
datos que debemos introducir al decidir qué impresora y monitor le conectaremos". 

Chip modifica el formulario con los cambios sugeridos y consigue la aprobación defini¬ 
tiva de Dot. El formulario terminado se muestra en la figura E12.1. Observe la división en 
zonas y el uso de las marcas que indican la cantidad de caracteres que se deben teclear. Es¬ 
to ayuda al usuario a decidir la manera de abreviar los datos que no quepan en el campo del 
archivo o la base de datos. 

Una vez que termina el formulario. Chip se dedica a modificar la pantalla donde se in¬ 
troducirán los datos del formulario. La pantalla de entrada ADD NEW COMPUTER se 
muestra en la figura E12.2. 

Dos de los aspectos de la pantalla de entrada que se deben tomar en cuenta son la faci¬ 
lidad y la precisión para introducir los datos. Otro aspecto es la disponibilidad de ayuda. Los 
empleados nuevos no conocerán la forma de operar el sistema o lo que se requiere introdu¬ 
cir en un campo determinado. Para alcanzar estos objetivos. Chip incluye listas desplegables 
para MONITOR, PRINTER, NETWORK CONNECTION y COMPUTER BOARDS. "Me 
agrada la forma en que funcionan estas listas desplegables", le dice a Anna. "Los usuarios 
pueden seleccionar fácilmente los códigos que deben encontrarse almacenados en la base 
de datos." 

"No hay razón para que los usuarios seleccionen códigos", contesta Anna. "Debe haber 
alguna manera de que seleccionen conceptos que describan códigos, como el nombre de la 
impresora, y que la computadora almacene los códigos." 

"[Qué excelente ideal", exclama Chip. Poco después, implementa las modificaciones. 


. míicps,!! 
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Anna revisa la pantalla y comenta: "[Esto se ve muy bien! Me gusta la manera en que 
agrupaste las casillas de verificación y la información descriptiva de las listas desplegables". 

"Mira esto", responde Chip. "Agregué un botón para que los usuarios cierren el formu¬ 
lario una vez que introduzcan todos los datos y realicen todas sus selecciones. También pue¬ 
den imprimir el formulario." 

"¿Y la ayuda?", pregunta Anna. 
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Listas desplegabas en la pantalla ADD NEW COMPUTER de Microsoft Access. 


"También pensé en ella", responde Chip. "Conforme el cursor pasa de un campo a otro, 
la línea de estado que se encuentra en la parte inferior de la pantalla despliega información 
relacionada con dicho campo. También incorporé sugerencias en pantalla, pequeños recua¬ 
dros con opciones de ayuda que aparecen cuando el cursor permanece durante algunos 
momentos sobre un área de entrada." Observe que las listas desplegables tienen nombres 
descriptivos en las áreas de datos. Hay espacio para tres tarjetas internas para la computado¬ 
ra en el área de entrada BOARD CODE. Las barras de desplazamiento proporcionan áreas 
de entrada adicionales si se requieren. La ayuda se despliega en la línea de estado en la par¬ 
te inferior de la pantalla. 

Dot revisa la pantalla terminada e introduce algunos datos de prueba. "[Estoy realmen¬ 
te impresionada!", exclama. "Es más fluida de lo que esperaba. ¿Cuándo podemos esperar el 
resto del sistema?" Chip sonríe con agradecimiento y comenta que se están haciendo pro¬ 
gresos considerables. "[Espero que el uso del resto del sistema sea igual de claro y fácil de 
operar!", dice Dot elogiosamente. 

Mientras tanto, Anna se reúne con Hy Perteks, quien busca ayuda con desesperación. 
"[Estoy abrumado por las solicitudes de ayuda relacionada con los paquetes de software! 
¿Existe alguna manera de diseñar una parte del sistema para ofrecer información sobre los 
expertos de software disponibles?", pregunta Hy. "Tengo nombres en pedazos de papel y 
siempre los pierdo. Con frecuencia me entero de quiénes son estos expertos después de que 
alguien más los encuentra primero que yo." 

Anna realiza algunas preguntas sobre la información que se requeriría y la manera en 
que Hy desearía conservar y desplegar los registros. Hy responde: "Hay mucho conocimien¬ 
to disponible, pero la única forma que tengo para encontrar la información sobre una perso- 
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na es utilizar su nombre como índice. Y, lo confieso, soy malo para recordar cómo se escribe 
correctamente el nombre, por no decir del apellido". Anna le asegura que pronto diseñará 
un sistema fácil de usar. 

De regreso a su escritorio, Anna piensa en el problema. "La pantalla ADD sería fácil de 
crear, ¿pero la pantalla CHANGE?" Se pregunta a sí misma: "¿Cómo la podré hacer?", y 
de repente piensa: "[Ah, ya sel", chasqueando los dedos. El diseño se aclara. Podría crear una 
pantalla con dos regiones distintas. La primera contendría el nombre y el apellido del exper¬ 
to en software. La pantalla incluiría un botón de búsqueda y botones para desplazarse por 
los registros. Si el usuario cometiera un error al introducir datos, habría un botón para des¬ 
hacer los cambios, al igual que un botón para guardar los cambios. La pantalla terminada se 
muestra en la figura E12.3. 

"Qué buena pantalla", dice Chip sonriente. "Quiero estar presente cuando se la mues¬ 
tres a Hy." 

Se requiere un enfoque distinto para el problema de eliminar registros de cursos para 
software que ya no se utiliza. Anna concluye que sería fácil utilizar la característica de bús¬ 
queda para localizar un registro y emplear a continuación un botón Find Next [Buscar si¬ 
guiente) para localizar el siguiente registro que coincida con los criterios de búsqueda. 
También podría proporcionar botones que permitieran desplazarse al registro siguiente o al 
anterior. (Vea el formulario DELETE SOFTWARE COURSE dentro de la base de datos 
para este capítulo en el sitio Web.) 

Una vez que se localiza el registro, el programa DELETE SOFTWARE COURSE des¬ 
plegaría la información correspondiente. Todos los códigos del archivo, como COURSE, 
LEVEL y OPERATING SYSTEM, se reemplazarían con la descripción completa del códi¬ 
go. En este punto no se podría modificar ninguna parte de los datos. El operador tendría la 
oportunidad de revisar el registro y decidir a continuación si eliminar o no el registro. Al 




































oprimir el botón para borrar, aparecería un cuadro de diálogo que le preguntaría al usuario 
si verdaderamente desea borrar el registro. En este punto, el usuario tendría la oportunidad 
de cancelar la eliminación. 

Hy queda encantado con los prototipos de pantalla. Al probar cada una de ellas, co¬ 
menta: "No saben lo fácil que será para mí responder las solicitudes de ayuda. [Esto es ge¬ 
nial!" Hace una larga pausa y después pregunta: "Me han pedido mucho que ofrezca cursos 
de capacitación programados de manera periódica. ¿Creen que podríamos trabajar en un 
sistema para registrarse a los cursos?" 

Anna hace una ligera mueca y dice: "¿Alguna vez han oído de los proyectos que avan¬ 
zan con demasiada lentitud, a los cuales siempre se les agregan cositas y nunca terminan? 
Pero bueno, la universidad tiene en marcha un proyecto de intranet y está buscando volun¬ 
tarios. Quizá podamos diseñar una página Web para registrarse a los cursos". 

"[Excelente!", responde Hy. "Esto es más de lo que hubiera esperado." 

Anna empieza a diseñar la página Web, incluyendo los nombres y apellidos de los usua¬ 
rios, al igual que sus direcciones de Internet y los teléfonos de sus oficinas. Se emplean áreas 
adicionales para introducir el campus donde se encuentran, el software que utilizan y su ni¬ 
vel de capacitación. Chip revisa el formulario y comenta: "En vez de hacer que los usuarios 
tecleen la información del campus y el software, ¿por qué no les ofrecemos la posibilidad de 
que la seleccionen de una lista desplegable? También podríamos permitirles que elijan los 
horarios de capacitación que sean más convenientes para ellos". 

"Buena idea", contesta Anna. "Y creo que los niveles de capacitación podrían colocarse 
en un grupo de botones de opción." La página Web final para la intranet se muestra en la 
figura E12.4. Observe que tiene botones para enviar la consulta o restablecer los valores 
predeterminados de las listas desplegables y los espacios. También contiene un vínculo pa¬ 
ra enviar preguntas a través de correo electrónico al encargado de la capacitación. 
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Hy está emocionado. "Este formulario es mejor de lo que imaginé. Creo que en realidad 
estamos ofreciendo una manera eficaz para registrarse a los cursos de capacitación, y sé que 
mi teléfono dejará de sonar tanto. [He tenido otra buena idea!" 

Usted puede realizar los siguientes ejercicios diseñando el informe o la pantalla me¬ 
diante formularios de diseño de impresora o de pantalla, o usando cualquier procesador de 
textos que conozca. Los campos y otra información relacionada con los informes se encuen¬ 
tran en las entradas del depósito de flujo de datos de Visible Analyst. En cada ejercicio se 
mencionan los nombres de los flujos de datos. 

Se han creado los informes y pantallas correspondientes (conocidos como formularios 
en Microsoft Access). Toda la información se encuentra en la base de datos de Microsoft Ac¬ 
cess; usted sólo tiene que modificar los informes y pantallas existentes para generar las ver¬ 
siones finales. Las modificaciones se realizan seleccionando el informe o pantalla deseado y 
haciendo clic a continuación en el botón Design [Diseño]. Se pueden hacer las siguientes 
modificaciones. El Page Header contiene los títulos de las columnas. El área Detail contie¬ 
ne los campos impresos del informe. 

Haga clic en un campo para seleccionarlo. Para seleccionar varios campos, haga clic en 
cada uno oprimiendo al mismo tiempo la tecla de mayúsculas. 

Arrastre un campo (o campos) seleccionado(s) para moverlo(s). 

Haga clic en cualquiera de los pequeños cuadros que rodean a un campo para cambiar 
el tamaño del mismo. 

Seleccione varios campos y haga clic en el botón Format y elija alguno de los siguientes 
comandos: 

Align, para alinear todos los campos en la parte superior, a la izquierda, etcétera. 

Size, para igualar la anchura o altura de los campos. 

Horizontal Spacing, para igualar el espaciado horizontal, o aumentar o disminuir el 

espaciado. 

Vertical Spacing, para igualar el espacio vertical, o aumentar o disminuir el espaciado. 


EJERCICIOS 

E-l. Cher Ware ha manifestado varias veces que un buen formulario debería facilitar la 
tarea de agregar nuevo software. También debería ofrecer documentación perma¬ 
nente para las adiciones de software. 

Diseñe un formulario para agregar software al SOFTWARE MASTER. Abra el 
Diagrama 0 en Visible Analyst y haga doble clic en el flujo de datos SOFTWARE 
RECEIVED FORM para ver su entrada en el depósito. Haga clic en NEW SOFT¬ 
WARE RECORD en el área Composition y haga clic en el botón Jump para ver la 
estructura de datos que contiene los elementos que se requieren en el formulario. Pa¬ 
se a cada elemento para determinar la longitud del campo en la pantalla. También 
podría utilizar las características Repository Reports y Single Entry Listing para im¬ 
primir una lista de elementos para el formulario. 

IP E-2. Diseñe la pantalla ADD SOFTWARE RECORD, ya sea en papel o modificando la 
pantalla de Access. Utilice los campos que elaboró en el ejercicio E-l. El nombre de 
la estructura de Visible Analyst es NEW SOFTWARE RECORD. 


Éfe Los ejercicios precedidos por un ¡cono Web indican que en el sitio Web del libro hay material de valor 
agregado. Los estudiantes pueden descargar una base de datos de Microsoft Access que pueden utilizar 
para completar los ejercicios. 
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E-3. A Hy Perteks le agradaría contar con un formulario para llenar conforme aprende 
acerca de nuevos expertos de software. Utilice la estructura de datos ADD SOFT¬ 
WARE EXPERT de Visible Analyst para determinar los campos que requeriría el 
formulario. 

E-4. Elabore la pantalla ADD SOFTWARE EXPERT en papel, con un procesador de 
texto o modificando el formulario de Access. Pruebe la pantalla ADD SOFTWARE 
EXPERT, utilizando las listas desplegables y observando la barra de estado en la par¬ 
te inferior de la pantalla. 

E-5. Diseñe o modifique el formulario de Access para la pantalla DELETE SOFTWARE 
EXPERT. ¿Cuáles campos son listas desplegables? Utilice la estructura de datos DE¬ 
LETE SOFTWARE EXPERT de Visible Analyst. 

E-6. Diseñe o modifique el formulario de Access para la pantalla DELETE COMPU¬ 
TER RECORD. La estructura de Visible Analyst se denomina DELETE COMPUTER 
RECORD. 

E-7. Cher Ware y Anna pasan la mejor parte de una mañana resolviendo los detalles de la 
porción de software del sistema. Cansada del problema de ofrecer constantes actua¬ 
lizaciones de software para todas las máquinas, Cher quisiera contar con un método 
de actualización sencillo. Unas cuantas versiones anteriores de software se podrían 
conservar para casos especiales. 

Parte de la solución es producir un informe, ordenado por ubicación, de todas las 
máquinas que contengan el software que debe actualizarse. Conforme se instala el 
nuevo software, se coloca una marca en el informe después de cada máquina. 

Diseñe la pantalla UPGRADE SOFTWARE. Agregue un botón Find para locali¬ 
zar el título y proporcionar un campo que se utilice para introducir el nuevo 
VERSIÓN NUMBER. El programa de actualización desplegará una línea por cada 
máquina que contenga la versión anterior del software instalado. Estas líneas se orde¬ 
nan por CAMPUS LOCATION y ROOM LOCATION. 

Las columnas son CAMPUS LOCATION, ROOM LOCATION, INVENTORY 
NUMBER, BRAND ÑAME, MODEL, UPGRADE y RETAIN OLD VERSIÓN. La 
columna UPGRADE contiene una casilla de verificación que se debe seleccionar si 
el software se actualizará. La casilla de verificación RETAIN OLD VERSIÓN aparece 
sin seleccionar de manera predeterminada. Los usuarios deben seleccionar la casilla si 
una máquina específica debe conservar las versiones nueva y anterior del software. 

Busque en la estructura de datos SOFTWARE UPGRADE de Visible Analyst los 
elementos contenidos en la pantalla. 

E-8. Explique la razón por la cual la pantalla UPGRADE SOFTWARE debería desplegar 
las máquinas en vez de que Cher introduzca los IDs de éstas. Describa en un párrafo 
por qué la pantalla muestra registros en una secuencia CAMPUS/ROOM. 

E-9. Diseñe la pantalla CHANGE SOFTWARE. Esta pantalla permite a Cher Ware mo¬ 
dificar datos introducidos de manera incorrecta, así como información que cambia 
de manera rutinaria, como SOFTWARE EXPERT y NUMBER OF COPIES. SOFT¬ 
WARE INVENTORY NUMBER es la clave principal y no debe cambiarse. Los demás 
campos del SOFTWARE MASTER que deben incluirse en la pantalla se encuentran 
en la estructura de datos SOFTWARE CHANGES de Visible Analyst. Utilice estos 
campos para diseñar la pantalla. En Access se ha creado una pantalla parcial CHANGE 
SOFTWARE RECORD. Utilice la característica Field List de Access para agregarle 
campos. Incluya los siguientes botones: Find, Find Next, Previous Record, Next 
Record, Save Record y Cancel Changes. 

E-10. A Hy Perteks le preocupa que los cursos sobre versiones obsoletas del software están 
atestando las unidades de disco. Cree e imprima la pantalla DELETE SOFTWARE 
COURSE. 
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Los campos de entrada son SOFTWARE TITLE, OPERATING SYSTEM y VER¬ 
SIÓN NUMBER. El programa despliega una línea por cada curso impartido sobre 
una versión de software. La primera columna contiene un campo de entrada con una 
D (de eliminar), de manera predeterminada. Si se coloca un espacio en el campo el 
registro no podrá eliminarse. Las demás columnas de cada línea son COURSE TITLE, 
LEVEL y CLASS LENGTH. Agregue un mensaje significativo para el operador. 

P E-l 1. Diseñe la pantalla UPDATE MAINTENANCE INFORMATION. Contiene campos 
de entrada que permiten a Mike Crowe cambiar la información de mantenimiento 
cada vez que se reparan las computadoras o cuando se les da mantenimiento de ruti¬ 
na. La estructura de datos de Visible Analyst es UPDATE MAINTENANCE IN¬ 
FORMATION. 
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OBJETIVOS DE APRENDIZAJE ;V.. 

Una vez que haya dominado el material de este capitula, podrá: 

. 1. Entender los conceptos de las bases de datos. 

2. Usar ia normalización para almacenar eficazmente los datos en una base de datos. 

3. Usar bases de datos para presentar datos:':J;: ; /:’-i:y 

4. Entender el concepto de almacenes de datos. 

5. Comprender la utilidad de publicar bases de datos en la Web. 


Algunos consideran que el almacenamiento de datos es el corazón de un sistema de infor¬ 
mación. Primero, los datos deben estar disponibles cuando el usuario desee utilizarlos. Se¬ 
gundo, los datos deben ser exactos y consistentes (deben tener integridad]. Además de estos 
requerimientos, los objetivos del diseño de base de datos incluyen el almacenamiento eficaz 
dedos datos ásí cómo su eficiente actualización y recuperación. Finalmente, es necesario 
que la recuperación de información tenga un propósito. La información obtenida de los : 
datos almacenados debe estar en una forma que sirva para administrar, planear, controlar o 
tomar decisiones en una organización. í.cAA;-'^-";' 

v En Un sistema basado en computadora hay dos enfoques para el almacenamiento de 
datos. El primero es almacenarlos datos en archivos individuales, cada uno para una aplica¬ 
ción específica. El segundo enfoque implica la construcción de una base de datos. Una base 
de datos es un almacén de datos definido formalmente y controlado centralmente, con el 
propósito de usarse en muchas aplicaciones diferentes. 

Los archivos convencionales seguirán siendo una forma práctica de almacenar datos pa¬ 
ra algunas aplicaciones (pero no para todas]. Un archivo se puede diseñar y construir con 
bastante rapidez, y cualquier asunto acerca de la disponibilidad y seguridad de los datos se 
minimiza. Cuando los diseños de archivos se planean con cuidado, se puede incluir toda la. 
información, necesaria y se reducirá el riesgo de omitir involuntariamente datos. 

El uso de archivos individuales tiene muchas consecuencias. A menudo los archivos se 
diseñan tomando en cuenta únicamente las necesidades inmediatas. Cuando se requiere 
consultar el sistema para obtener una:combinación de algunos de los atributos, estos últi¬ 
mos podrían encontrarse en archivos separados o quizá ni siquiera existan. Con frecuencia, 
el rediseño de los archivos implica que también los programas que tienen acceso a ellos se 
deben rescribir, lo cual se traduce en tiempo de programación costoso para el desarrollo y 
mantenimiento de archivos y programas. 



































Un sistema que usa archivos convencionales implica que los datos almacenados serán 
redundantes. Además, la actualización de archivos requiere más tiempo. Finalmente, la inte¬ 
gridad de los datos representa un problema, debido a que un cambio en un archivo también 
requerirá modificar los mismos datos en otros archivos. 


BASES DE DATOS 

Las bases de datos no son tan sólo una colección de archivos. Más bien, una base de datos es 
una fuente central de datos destinados a compartirse entre muchos usuarios para una diver¬ 
sidad de aplicaciones. El corazón de una base de datos lo constituye el sistema de adminis¬ 
tración de base de datos (DBMS, datábase management system), el cual permite la creación, 
modificación y actualización de la base de datos, la recuperación de datos y la generación de 
informes y pantallas. La persona encargada de garantizar que la base de datos cumpla sus 
objetivos se conoce como administrador de base de datos. 

Entre los objetivos de efectividad de la base de datos están los siguientes: 

1. Asegurar que los datos se puedan compartir entre los usuarios para una diversidad de 
aplicaciones. 

2. Mantener datos que sean exactos y consistentes. 

3. Asegurar que todos los datos requeridos por las aplicaciones actuales y futuras se podrán 
acceder con facilidad. 

4. Permitir a la base de datos evolucionar conforme aumenten las necesidades de los 
usuarios. 

5. Permitir a los usuarios construir su vista personal de los datos sin preocuparse por la 
forma en que los datos se encuentren almacenados físicamente. 

La anterior lista de objetivos nos proporciona un recordatorio de las ventajas y desventajas 
del enfoque de base de datos. Primero, la compartición de los datos significa que éstos deben 
almacenarse una sola vez. Como consecuencia, esto ayuda a lograr la integridad de los datos, 
debido a que los cambios en los datos se realizan con mayor facilidad y confiabilidad si 
éstos aparecen sólo una vez en lugar de en muchos archivos diferentes. 

Cuando un usuario necesita datos específicos, una base de datos bien diseñada anticipa¬ 
ría dicha necesidad (o quizás ya se habrían usado en otra aplicación]. Por lo tanto, es más 
probable que los datos estén disponibles en una base de datos que en un sistema de archi¬ 
vos convencional. Una base de datos bien diseñada también puede ser más flexible que los 
archivos separados; es decir, una base de datos puede evolucionar conforme cambien las ne¬ 
cesidades de los usuarios y las aplicaciones. 

Finalmente, el enfoque de base de datos tiene la ventaja de permitir a los usuarios ob¬ 
tener su propia vista de los datos. Los usuarios no tienen que preocuparse por la estructura 
real de la base de datos o su almacenamiento físico. 

Muchos usuarios extraen partes de la base de datos central desde mainframes y las des¬ 
cargan en sus PCs o en sus dispositivos portátiles. Después estas bases de datos más pequeñas 
se usan para generar informes o responder consultas específicas para el usuario final. 

Las bases de datos relaciónales para PCs se han perfeccionado de manera importante du¬ 
rante los últimos años. Un cambio tecnológico importante ha sido el diseño de software de 
base de datos que toma ventaja de la GUI. Con la llegada de programas tal como Microsoft 
Access, los usuarios pueden arrastrar y colocar campos entre dos o más tablas. Desarrollar 
bases de datos relaciónales con estas herramientas es relativamente fácil. 


CONCEPTOS DE DATOS 

Antes de considerar el uso de archivos o del enfoque de la base de datos, es importante enten¬ 
der cómo se representan los datos. En esta sección se tratan las definiciones críticas, incluyendo 
la abstracción de datos del mundo real para el almacenamiento de datos en tablas y relaciones 
de la base de datos. 
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REALIDAD, DATOS Y METADATOS 

Al mundo real se le llamará realidad. En la realidad, los datos recopilados de personas, lugares 
o eventos se almacenarán eventualmente en un archivo o una base de datos. Para entender 
la forma y estructura de los datos, se necesita información sobre los datos mismos. A la 
información que describe los datos se le llama metadatos. 

En la figura 13.1 se describe la relación entre realidad, datos y metadatos. Dentro del 
reino de la realidad hay entidades y atributos; dentro del reino de los datos reales hay ocurren¬ 
cias de registros y ocurrencias de datos, y dentro del reino de los metadatos hay definiciones 
de registros y definiciones de datos. Los significados de estos términos se analizan en las si¬ 
guientes subsecciones. 

Entidades Una entidad es cualquier objeto o evento sobre el cual alguien escoge reco¬ 
pilar datos. Una entidad podría ser una persona, lugar o cosa (por ejemplo, un vendedor, 
una ciudad o un producto). Cualquier entidad también puede ser un evento o unidad 
de tiempo tal como la avería de una máquina, una venta o un mes o año. Además de las 
entidades que se explicaron en el capítulo 2 hay una entidad menor adicional llamada 
subtipo de entidad. Su símbolo es un rectángulo más pequeño dentro del rectángulo de 
la entidad. 
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Un subtipo de entidad es una relación especial uno a uno que representa los atributos 
adicionales (campos) de otra entidad que podría no estar presente en cada registro de la pri¬ 
mera entidad. Los subtipos de entidades eliminan la posibilidad de que una entidad pueda 
tener campos nulos almacenados en las tablas de la base de datos. 

Un ejemplo es la entidad principal de un cliente. Los clientes preferidos podrían tener 
campos especiales que contengan información de descuentos especiales, y esta información 
estaría en un subtipo de entidad. Otro ejemplo son los estudiantes que tienen periodos de 
prácticas profesionales. El ARCHIVO MAESTRO DE ESTUDIANTES no debe contener 
información sobre los periodos de prácticas profesionales para cada estudiante, debido a 
que quizás sólo un número pequeño de estudiantes tiene dicho periodos. 


Los diagramas entidad-relación 
(E-R) pueden mostrar relaciones 
de uno a uno, uno a muchos, 
muchos a uno o muchos 


a muchos. 


Ejemplos de diagramas E-R Relaciones 
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Relaciones Éstas son asociaciones entre las entidades (a veces se conocen como asociacio¬ 
nes de datos). La figura 13.2 es un diagrama entidad-relación (E-R) que muestra varios tipos 
de relaciones. 

El primer tipo de relación es una relación uno a uno (designada como 1:1]. El diagrama 
muestra que sólo hay un PAQUETE DE PRODUCTOS para cada PRODUCTO. La segun¬ 
da relación uno a uno muestra que cada EMPLEADO tiene una sola OFICINA. Observe 
que todas estas entidades se pueden describir aún más (el precio de un producto no seria 
una entidad, ni una extensión telefónica). 

Otro tipo de relación es una relación uno a muchos (1 :M) o muchos a uno. Como se 
muestra en la figura, a un MÉDICO, en un centro de salud, se le asignan muchos PACIEN¬ 
TES, pero a un PACIENTE se le asigna un solo MÉDICO. Otro ejemplo muestra que un 
EMPLEADO es un miembro de un solo DEPARTAMENTO, pero cada DEPARTAMENTO 
tiene muchos EMPLEADOS. 

Finalmente, una relación muchos a muchos (designada como M:N) describe la posibi¬ 
lidad de que las entidades podrían tener muchas asociaciones en cualquier dirección. Por 
ejemplo, un ESTUDIANTE puede tener muchos CURSOS, y al mismo tiempo en un 
CURSO podría haber muchos ESTUDIANTES inscritos. El segundo ejemplo muestra que 
un VENDEDOR puede visitar muchas CIUDADES y una CIUDAD puede ser el área 
de ventas para muchos VENDEDORES. 

En la figura 13.3 se dan los símbolos estándar para la notación de tipo pata de cuervo, 
la explicación oficial de los símbolos y su significado real. Observe que el símbolo para una 
entidad es un rectángulo. Una entidad se define como una clase de persona, lugar o cosa. Un 
rectángulo con un diamante dentro simboliza una entidad asociativa, la cual se usa para unir 
dos entidades. Un rectángulo con un óvalo dentro representa una entidad atributiva, la cual 
se usa para los grupos repetitivos. 


Símholo : Explicación oficial Significado real 
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Las otras notaciones necesarias para dibujar los diagramas E-R son las conexiones, 
de las cuales hay cinco tipos diferentes. En la parte inferior de la figura se explica el sig¬ 
nificado de la notación. Cuando una línea recta conecta a dos entidades planas y el ex¬ 
tremo de la línea se marca con dos marcas cortas (II], existe una relación uno a uno. Lo 
siguiente que observará es una unión tipo pata de cuervo con una marca corta (I]; cuan¬ 
do esta notación vincula entidades, indica una relación uno a uno o uno a muchos (a 
uno o más]. 

Las entidades vinculadas con una línea recta más una marca corta (I] y un cero (el cual 
se parece más a un círculo. O] describen una relación uno a cero o uno a uno (sólo cero o 
uno]. Un cuarto tipo de vínculo para relacionar las entidades se dibuja con una línea recta 
marcada en el extremo con un cero (O] seguido por una conexión tipo pata de cuervo. Es¬ 
te tipo muestra una relación cero a cero, cero a uno o cero a muchos. Finalmente, una línea 
recta que vincula las entidades con una conexión tipo pata de cuervo en el extremo descri¬ 
be una relación de más de uno. 

Una entidad podría tener una relación que la conecte a sí misma. Este tipo de relación se 
llama relación recursiva; la implicación es que debe haber una forma de vincular un registro 
de un archivo a otro registro del mismo archivo. Un ejemplo de una relación recursiva se 
puede encontrar en las simulaciones de HyperCase que se mencionan en los capítulos. Una 
tarea podría tener una tarea precedente (es decir, una tarea que se debe completar antes de 
empezar la actual]. En esta situación, un registro (la tarea actual] apunta a otro registro (la 
tarea precedente] en el mismo archivo. 

Las relaciones se pueden escribir con palabras en la parte superior o al lado de cada 
línea de conexión. En realidad, usted ve la relación en una dirección, aunque puede escri¬ 
bir las relaciones en ambos lados de la línea, donde cada una representa el enfoque de una 
de las dos entidades. (Véase el capítulo 2 para más detalles sobre la ilustración de diagra¬ 
mas E-R.] 

Ejemplo de entidad-relación En la figura 13.4 se presenta un diagrama entidad-relación 
que contiene muchas entidades, muchos tipos diferentes de relaciones y varios atributos. En 
este diagrama E-R nos enfocamos en un sistema de facturación, y en particular con la parte 



El diagiamé entidad-relación para 
el tratamiento de un paciente. 
Los atributos se pueden listar al 
lado de las entidades. En cada 
caso, la clave se subraya. 



( Nombre-producto , 

nombre-paciente , 

descripción, 

fecha, 

síntoma) 


( Nombre-producto , 

dosis, 

fabricante, 

cantidad) 
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de la prescripción del sistema. (Por simplicidad, asumimos que las visitas al consultorio se 
manejan de forma diferente y están fuera del alcance de este sistema.) 

Las entidades son PRESCRIPCIÓN, MÉDICO, PACIENTE y COMPAÑÍA DE SE¬ 
GUROS. La entidad de TRATAMIENTO no es importante para el sistema de factura¬ 
ción, pero es parte del diagrama E-R porque se usa para establecer una conexión entre la 
PRESCRIPCIÓN y el PACIENTE. Por lo tanto lo dibujamos como una entidad asociati¬ 
va en la figura. 

Aquí, un MÉDICO trata muchos PACIENTES (1 :M), quienes se suscriben por separado 
a una COMPAÑÍA DE SEGUROS individual. Por supuesto, el PACIENTE es sólo uno de 
los muchos pacientes que se suscriben a dicha COMPAÑÍA DE SEGUROS particular 
(M:l). 

Para completar los registros del MÉDICO, el médico necesita guardar la información 
acerca de los tratamientos que tiene un PACIENTE. Muchos PACIENTES experimentan 
muchos TRATAMIENTOS, lo que se convierte en una relación muchos a muchos (M:N). 
El TRATAMIENTO se representa como una entidad asociativa porque no es importante en 
nuestro sistema de facturación por sí mismo. Los TRATAMIENTOS pueden incluir la toma 
de PRESCRIPCIONES, y por ello también es una relación M:N, debido a que muchos 
tratamientos podrían requerir combinaciones de fármacos y muchos medicamentos podrían 
funcionar para muchos tratamientos. 

Después algunos detalles se completan para los atributos. Los atributos se listan al lado 
de cada una de las entidades, y la clave se subraya. Por ejemplo, la entidad PRESCRIPCIÓN 
tiene un NOMBRE-PRODUCTO. DOSIFICACIÓN, FABRICANTE y CANTIDAD. En 
teoría, sería benéfico diseñar una base de datos de esta forma, usando diagramas entidad-rela¬ 
ción y después completando los detalles acerca de los atributos. Este enfoque de arriba abajo es 
provechoso, pero a veces es muy difícil lograr. 

Atributos Un atributo es una característica de una entidad. Puede haber muchos atribu¬ 
tos para cada entidad. Por ejemplo, un paciente (entidad] puede tener muchos atributos, 
tal como apellido, nombre, calle, ciudad, estado, etc. La fecha de última visita del paciente así 
como los detalles de la prescripción también son atributos. Cuando se construyó el diccio¬ 
nario de datos en el capítulo 8, el componente más pequeño descrito se llamó elemento de 
datos. Cuando los archivos y bases de datos se discuten, estos elementos de datos general¬ 
mente se conocen como datos. De hecho, estos datos son las unidades más pequeñas en un 
archivo o base de datos. El término datos también se usa de forma indistinta con la palabra 
atributo. 

Los datos pueden tener valores. Estos valores pueden ser de longitud fija o variable; 
pueden ser caracteres alfabéticos, numéricos, especiales o alfanuméricos. En la figura 13.5 
se pueden encontrar ejemplos de datos y sus valores. 

A veces un dato también se conoce como campo. Sin embargo, un campo representa 
algo físico, no lógico. Por lo tanto, muchos datos se pueden empaquetar en un campo; el 
campo se puede leer y convertir en varios datos. Un ejemplo común de esto es almacenar 
la fecha en un solo campo como MM/DD/AAAA. Para ordenar el archivo de acuerdo la fe¬ 
cha, se extraen por separado tres datos del campo y se ordenan primero por AAAA, luego 
por MM y finalmente por DD. 

Registros Un registro es una colección de datos que tiene algo en común con la entidad 
descrita. La figura 13.6 es una ilustración de un registro con muchos datos relacionados. 
El registro mostrado es para un pedido hecho con una compañía de ventas por correo. El 
#-PEDIDÓ. APELLIDÓ. INICIAL, CALLE, CIUDAD, ESTADO y TARJETA DE CRÉDITO 
son atributos. La mayoría de los registros son de longitud fija, de modo que no es necesario 
determinar la longitud todo el tiempo. 

Bajo ciertas circunstancias (por ejemplo, cuando el espacio es importante), se usan 
registros de longitud variable. Un registro de longitud variable se usa como alternativa para re¬ 
servar una gran cantidad de espacio para el registro más grande posible, tal como el número 
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LOS valores üpicus asignaüus 
a datos podrían ser números, 
caracteres alfabéticos, caracteres 
especiales y combinaciones de 
los tres. 


Entidad 

Datos 

Valor 

Vendedor 

Número del vendedor 

87254 • 


Nombre del vendedor 

Kaytell 


Nombre de la compañía 

Music Unlimited 


Dirección .T'f'T'JiL,ccft 

45 Arpeum Circle 


Ventas 

$20,765 

Paquete 

Ancho 

2 


Alto 

16 


Longitud 

16 


Peso 

3 


Dirección de envío 

765 Dulcinea Drive 


Dirección de devolución 

P.O. Box 341, SpringValley, MN 

Pedido 

Producto(s) 

B521 


Descripción(es) 

"My Fair Lady" disco compacto 


Cantidad pedida 

f .• i:,...;; 


Apellido del cliente i ; ;'i 

KiieyL. , : ,v' 


Inicial 

-•R.’-; .. ' 


Calleé v 

765 Dulcinea Drive 


Ciudad 

• La Mancha 


Estado 

CA ’ ■ 


Código postal 

,93407 . 


Número de la tarjeta de crédito 

65-8798-87. 


Fecha en la que se hizo el pedido 

05/0.1/2003 


Cantidad 

; $6,99:: 


Estado 

Nueva orden de pedido 


máximo de visitas que un paciente ha hecho a un médico. Cada visita podría contener mu¬ 
chos datos que serían parte del registro completo del paciente (o carpeta de archivo en un 
sistema manual). Más adelante en este capítulo, se discute la normalización de una relación. 
La normalización es un proceso que elimina los grupos repetitivos encontrados en los registros 
de longitud variable. 

Claves Una clave es uno de los datos en un registro que se usa para identificar al regis¬ 
tro. Cuando una clave identifica de forma única un registro, se llama clave primaria. Por 
ejemplo, #-PEDIDO puede ser una clave primaria porque a cada pedido del cliente se 
asigna un solo número. De esta forma, la clave primaria identifica la entidad real (pedido 
del cliente]. 

Si una clave no identifica de forma única un registro, se le llama clave secundaria. Las 
claves secundarias se pueden usar para seleccionar un grupo de registros que pertenecen a 
un conjunto (por ejemplo, pedidos que vienen del estado de Virginia). 

Cuando no es posible identificar de forma única un registro usando uno de los datos 
encontrados en un registro, se puede construir una clave seleccionando dos o más datos y 


Un registro tiene una clave 
primaria y podría tener muchos 
atributos. 


Registro 


í - - 1 

#-PEDIDQ 

APELLIDO:/ 

•INICIAL: 

: CALLE: : 

CIUDAD/ 

¡ESTADO 1 

•TARJETA DE CRÉDITO 


t 


Clave 


Atributos 
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Número del vendedor 
Nombre del vendedor 
Nombre de la compañía , 1 

Dirección ;!i : V. 
Ventas ,, 7 

Ancho 

Alto 

Longitud 

Peso 

Dirección de envío 
Dirección de devolución 

Producto(s) 

Descripción(es) . 

. Cantidad pedida ■' 

Apellido del cliente 

Ciudad : f : -- ;-:v• ■■ •j; ; ís;: 

■ Estado -r 

Código postal . .. 

Numero de la tarjeta de. crédito 
Fecha én la que se hizo el pedido 
. Cantidad ; ■;'' / N V' i 
Estado 


7.2 si^*' 03 * 

campo ocupa 

I dígW @ ' do6 , 
í) cuaip^ e&t . ma ¡ 

derecha. 



rawIEB T' .y 


los retddatx 'ncliayeri ivn 
descripción de cómo se deben 
ver los valores de cada dato 


MM/DD/AAAA 


i 5e Dodrian espe° 
l ficár formatos 
O especiales para 

á los campos. . 

. : : ’• • _ 

y md qvjj/jiü'^ - • 


combinándolos. Esta clave se llama clave concatenada. Cuando un dato se usa como clave 
en un registro, se subraya la descripción. Por lo tanto, en el registro PEDIDO T#-PF,PTPO . 
APELLIDO, INICIAL, CALLE, CIUDAD, ESTADO, TARJETA DE CRÉDITO), la clave 
es #-PEDIDO . Si un atributo es una clave en otro archivo, se debe subrayar con una línea 
punteada. 


Metadatos Los metadatos son datos que definen a los datos en el archivo o base de datos. 
Los metadatos describen el nombre dado y la longitud asignada a cada dato. Los metadatos 
también describen la longitud y composición de cada uno de los registros. 

La figura 13.7 es un ejemplo de metadatos para una base de datos perteneciente a al¬ 
gún software genérico. La longitud de cada dato se indica según una convención, donde 7.2 
significa que se reservan siete espacios para el número y que dos de esos dígitos están a la 
derecha del punto decimal. La letra N significa "numérico" y la A representa "alfanumérico". 
La D representa la "fecha" y está automáticamente en el formato MM/DD/AAAA. Algunos 
programas, tal como Microsoft Access, usan español común para los metadatos, de manera 
que se usan palabras tales como texto, dinero y número. Microsoft Access proporciona, de 
forma predeterminada, 50 caracteres como la longitud del campo para los nombres, lo cual 
está bien al trabajar con sistemas pequeños. Sin embargo, si trabaja con una base de datos 
grande para un banco o una compañía de servicios públicos, por ejemplo, no deberá destinar 
tanto espacio para dicho campo. De lo contrario, la base de datos crecería bastante y tendría 
demasiado espacio desperdiciado. En estos casos es cuando puede usar metadatos para anti¬ 
cipar la solución a posibles problemas futuros y diseñar una base de datos más eficaz. 
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ORGANIZACIÓN DE ARCHIVOS 


Un archivo contiene grupos de registros que proporcionan información para la operación, 
diseño, administración y toma de decisiones en una organización. Los tipos de archivos usados 
se describen primero, seguidos de una descripción de las muchas formas en que se pueden 
organizar los archivos convencionales. 

Tipos de archivo Los archivos se pueden usar para almacenar datos por un periodo indefini¬ 
do, o se pueden usar para almacenar datos temporalmente para un propósito específico. Los 
archivos maestros y de tabla se usan para almacenar datos por un periodo largo. Los archivos 
temporales normalmente se llaman archivos de transacción, archivos de trabajo o archivos de 
reporte. 

Archivos maestros. Los archivos maestros contienen registros para un grupo de enti¬ 
dades. Con frecuencia los atributos se podrían actualizar, pero los registros en sí son relativa¬ 
mente permanentes. Estos archivos son propensos a tener registros grandes que contienen 
toda la información sobre una entidad de datos. Cada registro normalmente contiene una 
clave primaria y varias claves secundarias. Los archivos maestros se encuentran como tablas 
en una base de datos o como archivos indexados o del tipo indexado-secuencial. 

Aunque el analista es libre de distribuir en cualquier orden los elementos de datos en 
un archivo maestro, una distribución estándar es poner primero el campo de clave primaria, 
seguido por los elementos descriptivos y finalmente por elementos que reflejan el negocio y 
cambian frecuentemente con las actividades del negocio. Este procedimiento permite a los 
analistas, o a otras personas que tienen acceso a estos archivos, identificar fácilmente los re¬ 
gistros cuando un archivo se lista con una rutina de impresión. 

La información descriptiva son datos que no cambian con los eventos del negocio, tal 
como una descripción del artículo, nombre del cliente, dirección o departamento del em¬ 
pleado. Estos elementos normalmente se cambian por programas de mantenimiento que 
usan métodos de acceso directo. Normalmente, estos elementos contienen claves alternas o 
índices, y los datos están en un formato de despliegue. 

Los elementos de información del negocio son aquellos que cambian periódicamente 
con los eventos del negocio, tales como sueldo bruto acumulado en el año, promedio de ca¬ 
lificaciones, saldo de la cuenta del cliente y la fecha de la última compra del cliente. Estos 
elementos son modificados por programas de actualización que, por eficiencia, normalmente 
leen tanto los archivos como los registros que coinciden de manera secuencial. Los elemen¬ 
tos del registro sólo son modificados por los programas cuando los datos tienen algún error, 
usando métodos aleatorios de actualización. Con frecuencia los campos de tipo monetario 
(dólares o pesos] están en un formato de datos comprimido llamado decimal condensado 
para ahorrar espacio en los archivos y acelerar el tiempo de ejecución del programa. 

Si el archivo maestro se almacena usando métodos convencionales, se reserva un área 
de expansión al final de cada registro. Esta área proporciona espacio para agregar nuevos 
campos al registro conforme cambien las necesidades del negocio. Si el archivo es parte de 
una estructura de la base de datos, no se requiere el área de expansión. Entre los ejemplos 
de un archivo maestro se incluyen los registros de pacientes, registros de clientes, un archi¬ 
vo de personal y un archivo de inventario de partes. 

Archivos de tabla. Un archivo de tabla contiene datos usados para calcular más datos 
o medidas de desempeño. Un ejemplo es una tabla de tasas de correos usada para determinar 
los gastos de envío de un paquete. Otro ejemplo es una tasa de impuestos. Normalmente los 
archivos de tabla se leen únicamente por un programa. 

Archivos de transacción. Un archivo de transacción se usa para hacer cambios que 
actualizan el archivo maestro y producen informes. Suponga que el archivo maestro de un 
suscriptor de periódico necesita ser actualizado; el archivo de transacción contendría el nú¬ 
mero del suscriptor y un código de transacción tal como E para extender la suscripción, C 
para cancelar la suscripción o A para cambiar la dirección. Después sólo se necesita introdu¬ 
cir la información relevante para la actualización; es decir, la longitud de renovación si es E 
o la dirección si es A. Si la suscripción fue cancelada no se necesitaría ninguna información 
adicional. El resto de la información ya existe en el archivo maestro. Como resultado, nor- 
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malmente los archivos de transacción se mantienen a una longitud mínima. Los archivos de 
transacción podrían contener varios tipos diferentes de registros, tales como los tres usa¬ 
dos para actualizar el maestro de suscriptores a un periódico, con un código en el archivo de 
transacción que indica el tipo de transacción. 

Archivos de trabajo. Algunas veces un programa se puede ejecutar con mayor eficacia 
si se usa un archivo de trabajo. Un ejemplo común de un archivo de trabajo es cuando se reor¬ 
dena un archivo para acceder a los registros con mayor rapidez para cierto tipo de procesos. 

Archivos de reporte. Cuando se necesita imprimir un informe y no hay ninguna im¬ 
presora disponible (por ejemplo, cuando la impresora está ocupada imprimiendo otros traba¬ 
jos], se usa un archivo de reporte. Enviar la salida a un archivo en lugar de a una impresora se 
denomina spooling. Después, cuando el dispositivo está listo, el documento se puede imprimir. 
Los archivos de reporte son muy útiles, debido a que los usuarios pueden tomar los archivos 
de otros sistemas de cómputo y enviarlos a dispositivos especializados tales como graficado- 
res, impresoras láser, unidades de microficha e incluso máquinas de composición tipográfica 
computarizadas. 

Organización secuencial Cuando los registros están físicamente en orden en un archivo, se di¬ 
ce que éste es un archivo secuencial. Cuando un archivo secuencial se actualiza, es necesario 
pasar por el archivo entero. Debido a que los registros no se pueden insertar en medio del archi¬ 
vo, normalmente se copia un archivo secuencial completo durante el proceso de actualización. 

La figura 13.8 ilustra un archivo de pedidos actuales para una compañía de ventas por 
correo que vende CDs de música. El archivo contiene 12 registros y se almacena en forma 
secuencial según el #-PEDIDQ. Si queremos buscar el pedido 13432, tendríamos que em¬ 
pezar desde el principio y leer todo el archivo hasta llegar a dicho pedido. 

Los archivos maestros secuenciales se usan cuando el hardware lo requiere (recuerde que 
una cinta magnética es un dispositivo secuencial] o cuando el acceso normal requiere que la 
mayoría de los registros se acceda. Es decir, cuando necesitamos leer o actualizar sólo unos 
registros, es ineficaz usar una estructura secuencial, pero cuando se necesita leer o modificar 
muchos registros, la organización secuencial tendría sentido. Normalmente la organización 
secuencial se usa para todos los tipos de archivos excepto los archivos maestros. 

Listas enlazadas Cuando los archivos se almacenan en dispositivos de acceso directo tal co¬ 
mo un disco, las opciones se extienden. Los registros se pueden ordenar lógicamente, en lugar 
de físicamente, usando listas enlazadas. Las listas enlazadas se logran usando un conjunto de 
indicadores para dirigirlo al próximo registro lógico ubicado en cualquier parte del archivo. 

La figura 13.9 muestra el archivo que ordena los CDs de música con un atributo adicio¬ 
nal usado para almacenar el indicador. Debido a que el archivo ya está almacenado en orden 
secuencial de acuerdo con el #-PEDIDO. el indicador se usa para apuntar a los registros en or¬ 
den lógico (alfabético] por el APELLIDO. Este ejemplo muestra una ventaja obvia de usar las 
listas enlazadas: los archivos se pueden ordenar de forma lógica de muchas maneras diferentes 
usando una variedad de indicadores. 
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Una lista enlazada usa 
indicadores para designar^ 
el orden lógico de los registros. 
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CA 
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M 

: .1986Ba.rnu.mCir. ..L 

London ' , 

;mh 
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Í;$ilÍ^t3432''T’ ' 

Cullum 

. J 

:354 River Road: 

Shenandoah 

• VT 

45-8734 33 

: .;['I:3TLV 
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Mostel 
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Organización de un archivo hash Los dispositivos de acceso directo también permiten 
acceso a un registro dado yendo directamente a su dirección. Debido a que no es factible 
reservar una dirección física para cada registro posible, se usa un método llamado hashing 
(reordenamiento). Hashing es el proceso de calcular una dirección a partir de la clave del 
registro. 

Suponga que en una organización había 500 empleados y quisimos usar el número de 
seguros social como una clave. Sería ineficaz reservar 999,999,999 direcciones, una para cada 
número de seguros social. Por lo tanto, podríamos tomar el número de seguros social y usar¬ 
lo para derivar la dirección del registro. 

Hay muchas técnicas de hashing. Una común es dividir el número original entre un nú¬ 
mero primo que se aproxime a las ubicaciones de almacenamiento y después usar el residuo 
como la dirección, como sigue: empiece con el número de seguros social 053-46-8942. Des¬ 
pués divida entre 509, para obtener 105,047. Observe que 105,047 multiplicado por 509 
no es igual al número original; en cambio es igual a 53,468,923. La diferencia entre el nú¬ 
mero original, 53,468,942, y el dividendo, 53,468,923, es el residuo, y es igual a 19. De tal 
manera, la ubicación de almacenamiento del registro para un empleado cuyo número de se¬ 
guros social es 053-46-8942 sería 19. 

Sin embargo, surge un problema cuando una persona con un número de seguro social 
diferente (por decir, 472-38-4086] tiene el mismo residuo. Cuando esto ocurre, el registro 
de la segunda persona se debe poner en un área de reserva especial. 


BASES DE DATOS RELACIÓNALES 

Las bases de datos se pueden organizar de varias formas. Aquí consideraremos el enfoque 
más común, la base de datos relacional. 


Vistas lógicas y físicas de datos Una base de datos, a diferencia de un archivo, es diseñada 
para ser compartida por muchos usuarios. Está claro que todos los usuarios ven los datos 
de formas diferentes. Nos referiremos a la forma en que un usuario visualiza y describe los da¬ 
tos como una vista de usuario. Sin embargo, el problema es que diferentes usuarios tienen 
vistas de usuario distintas. El analista de sistemas debe examinar estas vistas y debe desarro¬ 
llar un modelo lógico global de la base de datos. Finalmente, dicho modelo lógico se debe 
transformar en el diseño físico correspondiente de la base de datos. El diseño físico descri¬ 
be la forma como se almacenan y relacionan los datos, así como también la forma en que se 
acceden. 

En la literatura de base de datos, las vistas se denominan esquema. La figura 13.10 
muestra cómo el informe de usuario y la vista de usuario (esquema de usuario) se relaciona 
al modelo lógico (esquema conceptual) y al diseño físico (esquema interno). 
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El diseño de bases de datos 


incluye el sintetizar los informes 
de los usuarios, vistas de usuarios 
y los diáeños lógicos al igual que 
los físicos. 


Hay tres tipos principales de bases de datos estructuradas de forma lógica: jerárquica, 
red y relacional. Los primeros dos tipos se pueden encontrar en sistemas heredados (anti¬ 
guos). Hoy en día, un analista típicamente diseñaría una base de datos relacional. 

Estructuras relaciónales de datos Una estructura relacional de datos consiste en una o 
más tablas bidimensionales, las cuales se denominan relaciones. Las filas de la tabla repre¬ 
sentan registros y las columnas contienen atributos. 

En la figura 13.11 se denomina estructura relacional a la base de datos que ordena los CDs 
de música descrita anteriormente en este capítulo. Aquí, se necesitan tres tablas para (1) descri¬ 
bir los artículos y Uevar un registro del precio actual de CDs (PRECIO DEL ARTÍCULO), (2) 
describir los detalles del pedido (PEDIDO) y (3) identificar el estado del pedido (ESTADO 
DEL ARTÍCULO). 

Para determinar el precio de un artículo, necesitamos saber el número del artículo 
para poder encontrarlo en.la relación PRECIO DEL ARTÍCULO. Para actualizar el nú¬ 
mero de tarjeta de crédito de G. MacRae, podemos investigar la relación de PEDIDO 
para MacRae y corregirla una sola vez, aunque haya pedido muchos CDs. Sin embargo, pa¬ 
ra averiguar el estado de una parte de un pedido debemos saber el #-ARTÍCULO y el 
#-PEDIDO y después debemos localizar esa información en la relación ESTADO DEL 
ARTÍCULO. 

Normalmente, mantener las tablas en una estructura relacional es bastante simple 
en comparación con mantenerlas en una estructura jerárquica o de red. Una de las prin- 
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relaciónales, los datos se 
almacenan en muchas tablas. 


PRECIO DEL ARTÍCULO 


#-ARTICULO 

TITULO 

PRECIO ¡ 

... B235 

Guys and Dolls 

. "8,99 ; 

B521 

: MyFairLady 

•6.99 ¡í 

B894 . 

42nd Street *-.... 

• 10.99 f; 

B992 

AChorusLine. ;• . 

10.99' \ 


PEDIDO 


#-PEDID0 

APELLIDO 

i 

CALLE 

CIUDAD 

ES 

CUENTA DE COBRO í 

10784 

MácRáe 

G 

2314Cúr|yCircle : ; 

. Lincoln 
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45-4654-76 f 

10796 

Jones; 

S 

34 DreamLane . > 

Oklahoma City 

CK 

44:9876-74 ; 

11821 

Preston 

;R 

1008 Madison Ave. .:• 

River City * 

IÁ-: 

. 34.-7642-64 

11845 

Channing 

C 

454 Harmonía St.‘ 

New Y ork 

NT 

34-0876-87 

11872 

: Kiley •: 

R 

765 Dulcinea Drive v \ 

•La Mancha "•••: ' 

* 
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ESTADO DEL ARTÍCULO 


#-ARTiCULO 

/-PEDIDO 

ESTADO 

B235 

,10784 

Enviado 5/12 

B235 

19796 

Enviado 5/14 

B235 ,. 

11872 

En proceso. • .: v ; 

B521 

¡11821 : : 

En proceso'v / j 

;B894 

11845. • 

Nueva orden de pedido : 

B894 

11872: 

Enviado 5/12 

B992 

10784 

Enviado 5/12 


cipales ventajas de las estructuras relaciónales es que las consultas ad hoc se manejan efi¬ 
cazmente. 

Cuando se discuten las estructuras relaciónales en la literatura de base de datos, con 
frecuencia se usa una terminología diferente. Un archivo se conoce como tabla o relación, un 
registro normalmente se denomina tupia y el conjunto de valores de un atributo se llama 
dominio. 

Para que las estructuras relaciónales sean útiles y manejables, primero se deben normali¬ 
zar las tablas relaciónales. La normalización se detalla en la sección siguiente. 


NORMALIZACIÓN 

La normalización es la transformación de las vistas de usuario complejas y del almacén de 
datos a un juego de estructuras de datos más pequeñas y estables. Además de ser más sim¬ 
ples y estables, las estructuras de datos normalizadas son más fáciles de mantener que otras 
estructuras de datos. 

LOS TRES PASOS DE LA NORMALIZACIÓN 

Ya sea que empiece con una vista de usuario o un almacén de datos desarrollado para un 
diccionario de datos (véase el capítulo 8), el analista normaliza una estructura de datos en 
tres pasos, como se muestra en la figura 13.12. Cada paso involucra un procedimiento im¬ 
portante, el cual simplifica la estructura de datos. 

La relación derivada de la vista de usuario o del almacén de datos probablemente no 
estará normalizada. El primer paso del proceso incluye quitar todos los grupos repetiti¬ 
vos e identificar la clave primaria. Para ello, la relación se debe dividir en dos o más rela- 
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Vistas 
de usuario 





La normalización de una 
relación se realiza en tres 
pasos impórtenles. 


dones. A estas alturas, las relaciones ya podrían ser de la tercera forma normal, pero pro¬ 
bablemente se necesitarán más pasos para transformar las relaciones a la tercera forma 
normal. 

El segundo paso asegura que todos los atributos sin clave son totalmente dependientes 
de la clave primaria. Todas las dependencias parciales se remueven y se ponen en otra 
relación. 

El tercer paso remueve cualesquier dependencias transitivas. Una dependencia tran¬ 
sitiva es aquella en la que los atributos sin clave son dependientes de otros atributos sin 
clave. 


EJEMPLO DE NORMALIZACIÓN 


La figura 13.13 es una vista de usuario para la Al S. Well Hydraulic Equipment Company. 
El informe muestra el (1) NÚMERO-VENDEDOR, (2) NOMBRE-VENDEDOR y (3} 
ÁREA-VENTAS. El cuerpo del informe muestra el (4] NÚMERO-CLIENTE y (5} NOM¬ 
BRE-CLIENTE. Luego está (6) NÚMERO-ALMACÉN que servirá al cliente, seguido por 
(7] UBICACIÚN-ALMACÉN, la cual es la ciudad en donde se localiza la compañía. La úl¬ 
tima información contenida en la vista de usuario es la [8] CANTIDAD-VENTAS. Las filas 
[una para cada cliente] en la vista de usuario muestran que los artículos 4 a 8 forman un 
grupo repetitivo. 

Si el analista usara un enfoque de flujo de datos/diccionario de datos, la misma in¬ 
formación en la vista de usuario aparecería en una estructura de datos. La figura 13.14 
muestra cómo aparecería la estructura de datos en el paso del diccionario de datos del 
análisis. El grupo repetitivo también se indica en la estructura de datos con un asterisco 
(*} y con sangría. 












# del Vendedor; 3462 
Nombre: WatersW 
Área de ventas: Oeste 



Antes de proceder, observe las asociaciones de datos de los elementos de datos de la figu¬ 
ra 13.15. Este tipo de ilustración se denomina diagrama de burbuja o diagrama de modelo de 
datos. Cada entidad se encierra en una elipse, y las flechas se usan para mostrar las relaciones. 
Aunque es posible dibujar estas relaciones con un diagrama E-R, a veces es más fácil usar el 
diagrama de burbuja más simple para modelar los datos. 

En este ejemplo, sólo hay un NÚMERO-VENDEDOR asignado a cada NOMBRE- 
VENDEDOR, y esa persona cubrirá sólo un ÁREA-VENTAS, pero cada ÁREA-VENTAS 
se podría asignar a muchos vendedores: por ello, la notación de flecha doble del ÁREA- 
VENTAS al NÚMERO-VENDEDOR. Para cada NÚMERO-VENDEDOR, podría haber 
muchos NÚMEROS-CLIENTES. 

Además, habría una correspondencia de uno a uno entre NÚMERO-CLIENTE y 
NOMBRE-CLIENTE; lo mismo se aplica para NÚMERO-ALMACÉN y UBICACIÓN-AL¬ 
MACÉN. El NÚMERO-CLIENTE tendrá sólo un NÚMERO-ALMACÉN y UBICACIÓN- 
ALMACÉN, pero cada NUMERO-ALMACÉN o UBICACIÓN-ALMACÉN podrían servir 



d ahalbía püuñd eñT-uHuSr 
una estructura de datos (de un 
diccionario de datos) útil en 


el desarrollo de una base de NÚMERO-VENDEDOR 

datos - NOMBRE-VENDEDOR 

ÁREA-VENTAS 
NÚMERO-CLIENTE* (1-) 
NOMBRE-CLIENTE 
NÚMERO-ALMACÉN 
UBICACIÓN-ALMACÉN 
CANTIDAD-VENTAS 
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Dibujar diagramas de modelo 
de datos para las asociaciones de 
datos algunas veces ayuda a 
analistas a apreciar la complejidad 
del almacén de datos. 


a muchos NÚMERO-CLIENTE. Finalmente, para determinar la CANTIDAD-VENTAS 
para las visitas de un vendedor a una compañía particular, es necesario saber el NÚMERO- 
VENDEDOR y el NÚMERO-CLIENTE. 

El objetivo principal del proceso de la normalización es simplificar todos los datos 
complejos que se encuentran a menudo en las vistas de usuario. Por ejemplo, si el analista 
tomara la vista de usuario descrita arriba y hubiera intentado extender una tabla relacional 
de ella, la tabla se vería como la figura 13.16. Debido a que esta relación se basa en nuestra 
vista de usuario inicial, la denominaríamos INFORME-VENTAS. 

El INFORME-VENTAS es una relación sin normalizar, debido a que tiene grupos 
repetitivos. También es importante observar que un solo atributo tal como NÚMERO- 
VENDEDOR no puede servir como la clave. La razón queda clara cuando alguien exa¬ 
mina las relaciones entre el NÚMERO-VENDEDOR y los otros atributos en la figura 
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SI los datos fueran listados en 

una tabla sin normalizar, podría 
haber grupos repetidos. 
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Un diagrama de modelo de 
datos muestra que en una 
relación sin normalizar, el 
NÚMERO-VENDEDOR tiene 


una relación uno a muchos 
con algunos atributos. 








13.17. Aunque hay una correspondencia de uno a uno entre el NÚMERO-VENDEDOR 
y dos atributos (NOMBRE-VENDEDOR y ÁREA-VENTAS), hay una relación uno a 
muchos entre el NÚMERO-VENDEDOR y los otros cinco atributos (NÚMERO- 
CLIENTE, NOMBRE-CLIENTE, NÚMERO-ALMACÉN, UBICACIÓN-ALMACÉN y 
CANTIDAD-VENTAS). 

El INFORME-VENTAS se puede expresar en la siguiente notación de abreviatura: 


INFORME (NÚMERO-VENDEDOR, 

DE VENTAS NOMBRE-VENDEDOR, ÁREA-VENTAS, 
(NÚMERO-CLIENTE, 
NOMBRE-CLIENTE, 
NÚMERO-ALMACÉN, 
UBICACIÓN-ALMACÉN, 
CANTIDAD-VENTAS)) 


donde el juego interno de paréntesis representa el grupo repetitivo. 

Primera forma normal (INF) El primer paso para normalizar una relación es remover los 
grupos repetitivos. En nuestro ejemplo, la relación sin normalizar INFORME-VENTAS se 
separará en dos relaciones separadas. Estas nuevas relaciones se nombrarán VENDEDOR y 
VENDEDOR-CLIENTE. 

La figura 13.18 muestra cómo se normaliza la relación original sin normalizar INFORME- 
VENTAS al separar la relación en dos nuevas relaciones. Observe que la relación VENDEDOR 
contiene la clave primaria NUMERO-VENDEDOR y todos los atributos que no eran repe¬ 
titivos (NOMBRE-VENDEDOR y ÁREA-VENTAS). 

La segunda relación, CLIENTE-VENDEDOR, contiene la clave primaria de la rela¬ 
ción VENDEDOR (la clave primaria de VENDEDOR es NUMERO-VENDEDOR! , así 
como también todos los atributos que eran parte del grupo repetitivo (NÚMERO- 
CLIENTE, NOMBRE-CLIENTE, NÚMERO-ALMACÉN, UBICACIÓN-ALMACÉN y 
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INFORME DE LAS VENTAS 

NÚMERO NOMBRE ÁREA 

VENDEDOR VENDEDOR VENTAS 


MÚMERO 

NOMBRE 

NÚMERO 

UBICACIÓN 

CANTIDAD 

I[ CUENTE 

CUENTE 

: ALMACÉN 

ALMACÉN 

VENTAS ; 


' VENDEDOR 

J 

"1 

NÚMERO 

VENDEDOR 

NOMBRE 

VENDEDOR 

ÁREA j 
VENTAS | 

3462 

Waters ¿U); 

Oeste ] 

3593 

;:ffi¡j:;íí;Pryne1;:L:A 

' úEsté : v: l 
- : il 

I etc: : 


' •• j 


VENDEDOR-CUENTE 



NÚMERO 

VENDEDOR 

NÚMERO 

CLIENTE 

NOMBRE 

CUENTE 

i NÚMERO 
ALMACÉN 

UBICACIÓN 

ALMACÉN 

CANTIDAD 

VENTAS 
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13540 
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18830 

A. Levy and Sons 
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Bismarck 

10600 

34 £2 ■ 

19242 

RamerCompany 
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9700 

.3593 i 

'/] 8841:531; 

R. W. Flood Inc. 


Superior 

11560 

.3.593:. i 

18899 

Seward Systems 


Super¡or?í¡;¡ 

i 2590 

3593 

19565 

Stodola's Inc. . 


Plymouth i 

8800 


La relación sin normalizar 
original INFORME-VENTAS 
se divide en dos relaciones;: 
VENDEDOR (3NF)' : y.O :5' 

: CLIENIE VENDEDOR^ C 
(INF); "/í--:": /-■- r --: = 


CANTIDAD-VENTAS]. Sin embargo, debe saber que el NUMERO-VENDEDOR no 
significa automáticamente lo que usted sabrá del NOMBRE-CLIENTE, CANTIDAD- 
VENTAS, UBICACIÓN-ALMACÉN, etc. En esta relación, alguien debe usar una clave 
concatenada ( NÚMERO-VENDEDOR y NÚMERO-CLIENTE! para acceder al resto 
de la información. Es posible escribir las relaciones en notación abreviada como sigue: 

VENDEDOR (NUMERO-VENDEDOR. NOMBRE-VENDEDOR, 
ÁREA-VENTAS) 


CLIENTE-VENDEDOR 


( NUMERO-VENDEDOR, 

NÚMERO-CLIENTE, 

NOMBRE-CLIENTE, 

NÚMERO-ALMACÉN, 

UBICACIÓN-ALMACÉN, 

CANTIDAD-VENTAS) 


La relación CLIENTE-VENDEDOR es una relación de primera forma normal, pero no 
está en su forma ideal. Los problemas surgen porque algunos de los atributos no son 
funcionalmente dependientes de la clave primaria (es decir, NÚMERO-VENDEDOR . 
NÚMERO-CLIENTE ). En otras palabras, algunos de los atributos sin clave sólo son depen¬ 
dientes del NÚMERO DEL CLIENTE y no de la clave concatenada. El diagrama de modelo 
de datos de la figura 13.19 muestra que CANTIDAD-VENTAS es dependiente de NÚ : 












úú.' 



Un diagrama de modelo de 
datos muestra que tres 
atributos son dependientes 
del NÚMERO-CUENTE, de 
manera que la relación aún 
no se ha normalizado. El 
NÚMERO-VENDEDOR y 
el NÚMERO-CLIENTE se 


requieren para buscar la 
CANTIDAD-VENTAS. 



MF.RO-VF.NDF.DOR y de NÚMERO-CT JFNTF,. pero los otros tres atributos sólo son 
dependientes de NÚMERO-CLIENTE . 

Segunda forma normal (2NF) En la segunda forma normal, todos los atributos serán 
funcionalmente dependientes de la clave primaria. Por lo tanto, el próximo paso es qui¬ 
tar todos los atributos parcialmente dependientes y ponerlos en otra relación. La figura 
13.20 muestra cómo la relación VENDEDOR-CLIENTE es dividida en dos nuevas rela¬ 
ciones: VENTAS y ALMACÉN-CLIENTE. Estas relaciones también se pueden expresar 
como sigue: 

VENTAS (NÚMERO-VENDEDOR . NÚMERO-CLIENTE . 
CANTIDAD-VENTAS) 


y 


CLIENTE-ALMACÉN ÍNIJMERO-CLIENTE. 

NOMBRE-CLIENTE, 

NÚMERO-ALMACÉN, 

UBICACIÓN-ALMACÉN) 


La relación ALMACÉN-CLIENTE está en la segunda forma normal. Ésta todavía se puede 
simplificar más porque en la relación hay dependencias adicionales. Algunos de los atribu¬ 
tos sin clave son dependientes no sólo de la clave primaria, sino también de un atributo sin 
clave. Esta dependencia se denomina dependencia transitiva. 

La figura 13.21 muestra las dependencias en la relación ALMACÉN-CLIENTE. Para 
que la relación sea de la segunda forma normal, todos los atributos deben depender de la 
clave primaria NÚMERO-CLIENTE, como se muestra en el diagrama. Sin embargo, UBI¬ 
CACIÓN-ALMACÉN evidentemente también es dependiente de NÚMERO-ALMACÉN. 
Para simplificar esta relación, se requiere otro paso. 
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VENDEDOR-CLIENTE 


NÚMERO 

NÚMERO 

NOMBRE 

NÚMERO 

UBICACIÓN 

CANTIDAD 

VENDEDOR 

CLIENTE 

CUENTE 

ALMACÉN 

ALMACÉN 

VENTAS 


VENTAS 


y 


CLIENTE-ALMACEN 


NUMERO 

CLIENTE 

NOMBRE 

CUENTE 

NUMERO 

ALMACÉN 

UBICACIÓN 

ALMACÉN 



; V 

'. Fargo y- 

' 18830 \ 

A. Levy and Sons 

3 

Bismarck 

HHS 

Ranier Company.. 

3 l 

Blsm.arck 




Superior - 

pppippii!fp 

Seward Systems- :■ 

— A 2 

, Superior 

■ 1.9565 T ; 

Stodolas Inc 



étc v ....., 



i: '■ 


NÚMERO 

VENDEDOR 

NÚMERO 

CLIENTE 

CANTIDAD 

VENTAS 

3462 

\ 18765 

13540 . 

.ú£;,3462y; 

.18830. 

10600 

3462 

19242 : 

9700 

í 3593Cy 

iy;i,884iT:T;) 

: . 11560 

L- : -TX : 3593:-y|n| 

•'18899.' ... 

2590 

3593 

19565 

8800 

>. etc.T’T 'Tu..! 




La relación VENDEDOR-CUENTE 
se divide en una relación llamada ■ 
CLIENTE-ALMACÉN (2NF) y en- 
una relación llamada VENTAS 
(inf). 


Tercera forma normal (3NF) Una relación normalizada está en tercera forma normal si todos 
los atributos sin clave son funcionalmente dependientes por completo de la clave primaria 
y si no hay dependencias transitivas (sin claves). De forma similar a los pasos anteriores, es 
posible dividir la relación ALMACÉN-CLIENTE en dos relaciones, como se muestra en la 
figura 13.22. 




Un diagrama de modelo de 
datos muestra que entre el 
NUMERO-ALMACÉN y la 
: UBICACIÓN-ALMACÉN existe 
una dependencia transitiva. 


























CLIENTE-ALMACÉN 


La relación ULItNTL-ÁLMACLN 
se divide en dos relaciones 
llamadas CUENTE (INF) y 
ALMACÉN (INF). 


NUMERO 

CLIENTE 


NOMBRE 

CUENTE 


NUMERO 

ALMACÉN 


UBICACION 

ALMACÉN 


NÚMERO 

CLIENTE 

NOMBRE 

CLIENTE 

18765 - 

Delta Systems. 

18830 

A. Levy and Sons 

19242 

RamerCompany 

18841 

R. W. Flood Inc. 

18899 

Seward Systems 

19565 

Stodola's Inc. 

etc. 



NUMERO 

ALMACÉN 


NÚMERO 

ALMACÉN 

UBICACIÓN J 
ALMACÉN | 

U'4Á 

Fargp 

; 

Bismarck 

F2Ú-: ó . 

Superior 

C;t ;f: 

■ : j 

Plymouth : . i 

etc. 



Las dos nuevas relaciones se llaman CLIENTE y ALMACÉN y se pueden escribir como 


CLIENTE INUMERO-CLIENTE. NOMBRE-CLIENTE, 
NÚMER Or ALMAC ÉNJ 


ALMACEN JNIIMERO-ALMACEN. 

UBICACIÓN-ALMACÉN) 

La clave primaria para la relación CLIENTE es NUMERO-CLIENTE, y la clave primaria 
para la relación ALMACÉN es NUMERO-ALMACÉN . 

Además de estas claves primarias, podemos identificar el NUMERO-ALMACÉN para 
ser una clave externa en la relación CLIENTE. Una clave extranjera es cualquier atributo 
que no tiene clave en una relación pero es una clave primaria en otra. Designamos el 
NUMERO-ALMACÉN como una clave externa en la notación anterior y en las figuras 
subrayándolo con una línea punteada:_. 

Finalmente, la relación sin normalizar original INFORME-VENTAS se ha transforma¬ 
do en la cuarta relación de tercera forma normal (3NF). Al repasar las relaciones que se 
muestran en la figura 13.23, uno puede ver que la relación sencilla INFORME-VENTAS 
se transformó en las siguientes cuatro relaciones: 

VENDEDOR ÍNUMERO-VENDEDOR . NOMBRE-VENDEDOR, 
ÁREA-VENTAS) 

VENTAS ÍNÜMERO-VENDEDOR. NÚMERO-CLIENTE . 

CANTIDAD-VENTAS) 

CLIENTE ÍNUMERO-CLIENTE . NOMBRE-CLIENTE, 

NÚMERQr ALMACÉN) 


ALMACEN INUMERO-ALMACEN. 

UBICACIÓN-ALMACÉN) 


* 


i í¡8‘ I 


La tercera forma normal es adecuada para la mayoría de los problemas de diseño de bases 
de datos. La simplificación lograda al transformar una relación sin normalizar en un juego 
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VENDEDOR 


VENTAS 


NÚMERO 

VENDEDOR 

NÚMERO 

CLIENTE 

CANTIDAD 

VENTAS 

gll'U- 3462 

18765 . 

13540. 

3462” I, .i. j 

i 18830 ' 

. 10600 

3462 

' 19242 

9700 

,3593 

18841 

V 11560 

. 3593 

. 1.8899 . 

.2590 

V 3593 

19565 

8800 

■, etc.r'\ . 

: 'TÍ?.-. 



NÚMERO 

VENDEDOR 

NOMBRE 

VENDEDOR 

ÁREA ü 
VENTAS 

3462 

■ iiV'yvaters.LLLT 

i Oeste 

3593 

;i:vKPryni¿ii?£ 8 

Este 

-r'!:' i :.é tciVAVV 


•• 



La base de datos completa : 
consiste de cuatro relaciones 


INF llamadas VENDEDOR, . 
VENTAS, CLIENTE y ALMACÉN, 


CLIENTE ALMACÉN 


NÚMERO 

CLIENTE 

NOMBRE 

CUENTE 

NÚMERO 

ALMACÉN 

i;,: 18765 } . 

Delta Systems 

4 

18830 

A. Levy and Sons 

3 

i. : 19242.. V- 

RanierCompany 

3 

18841 ! :| 

R. W.. Floocl Inc. 

2 

.-i- 18899 " 

Seward Systems . 


19565- 

Stodola's Inc. 


etc 




NÚMERO 

ALMACÉN 

UBICACIÓN; 

ALMACÉN 

iyí'Sgi 

Fargo 


Bismarck 


Superior 


.: Plymouth 

etc. 



de relaciones 3NF es un gran beneficio cuando llega el momento de insertar, eliminar y ac¬ 
tualizar la información en la base de datos. 

En la figura 13.24 se muestra un diagrama entidad-relación para la base de datos. Un 
VENDEDOR sirve a muchos CLIENTES, quien genera VENTAS y recibe sus artículos de 
un ALMACEN (el ALMACEN más cercano a su ubicación). Tome el tiempo para observar 
cómo se relacionan las entidades y los atributos a la base de datos. 




Un diagrama entidad-relación 
para la base de datos de Al S. 
Well Hydraulic Company. 


(Número-almacén, 

ubicación-almacén) 
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Un diagrama entidad-relación 
para ¡os pedidos del cliente. 



coloca 

Pedido 

S4¿SSfi3LSlj£V!J J1S3 

| contiene 

1 



Articulo 


Número-pedido Número-artículo 

Número-cliente 


USO DEL DIAGRAMA ENTIDAD-RELACIÓN PARA DETERMINAR LAS CLAVES DEL REGISTRO 

El diagrama entidad-relación se podría usar para determinar las claves necesarias para una 
relación de un registro o de una base de datos. El primer paso es construir el diagrama enti¬ 
dad-relación y etiquetar una clave (principal) única para cada entidad de datos. La figura 
13.25 muestra un diagrama entidad-relación para un sistema de pedido de cliente. Hay tres 
entidades de datos: CLIENTE, con una clave primaria de NÚMERO -CLIENTE: PEDIDO, 
con una clave primaria de NÚMERO-PEDIDO, y ARTÍCULO, con NÚMERO-ÁRTÍCU- 
LO como la clave primaria, ún CLIENTE podría hacer muchos pedidos, pero cada PEDIDO 
podría hacerse por un solo CLIENTE, de modo que la relación es uno a muchos. Cada PE¬ 
DIDO podría contener muchos ARTÍCULOS, y cada ARTÍCULO podría estar contenido 
en muchos PEDIDOS, de manera que la relación del ARTÍCULO-PEDIDO es de muchos 
a muchos. 

Sin embargo, una clave externa es un campo de datos en un archivo dado que es la clave 
primaria de un archivo maestro diferente. Por ejemplo, un NÚMERO-DEPARTAMENTO 
que indica la especialidad de un estudiante podría existir en la tabla MAESTRO DE ES¬ 
TUDIANTES. El NÚMERO-DEPARTAMENTO también podría ser la única clave para la 
tabla MAESTRO DE DEPARTAMENTOS. 

RELACIÓN UNO A MUCHOS 

una tabla de base de datos no puede contener un grupo repetitivo o tabla, pero podría te¬ 
ner un archivo tradicional indexado de forma secuencial. El archivo en el extremo muchos 
podría tener claves externas almacenadas en una tabla dentro del archivo en el extremo 
uno. Por ejemplo, el MAESTRO DE CLIENTES podría diseñarse para contener una tabla 
de números de pedidos sobresalientes. La desventaja de usar dicha tabla del registro es que 
todas las entradas de la tabla se podrían completar con números de pedidos, y después el 
analista se enfrenta a la decisión de tener que extender la tabla (lo cual es costoso y requie¬ 
re tiempo) o de perder algunos datos de la tabla. 


RELACIÓN MUCHOS A MUCHOS 


Cuando la relación es de muchos a muchos, se necesitan tres tablas: una para cada entidad 
de datos y otra para la relación. Las entidades PEDIDO y ARTÍCULO de nuestro ejemplo 
tienen una relación muchos a muchos. La clave primaria de cada entidad de datos se almacena 
como una clave externa de la tabla relacional. Esta última podría contener simplemente las 
claves primarias para cada entidad de datos o podría contener datos adicionales, tales como 
la calificación recibida de un curso o la cantidad de un artículo pedido. Consulte el diseño 
de tabla ilustrado en la figura 13.26. La tabla ARTÍCULO DEL PEDIDO contiene infor¬ 
mación acerca de qué artículos contiene el pedido, y proporciona un vínculo entre la tabla 
PEDIDO y la tabla MAESTRO DE ARTÍCULOS. 

La tabla de relación se debe indexar en cada una de las claves externas —una para cada 
una de las tablas de la relación— y podría tener una clave primaria consistente en una com¬ 
binación de las dos claves externas. Para encontrar muchos registros en una segunda tabla 
dada la primera, lea directamente la tabla relacional para la clave deseada. Localice el regis¬ 
tro de coincidencia en la segunda tabla muchos. Continúe buscando en la tabla relacional 
hasta que ya no se encuentre la clave deseada. Por ejemplo, para encontrar registros en el 
MAESTRO DE ARTÍCULOS para un registro específico en la tabla PEDIDO, lea directa¬ 
mente la tabla ARTÍCULO DEL PEDIDO usando NÚMERO-PEDIDO como el índice. 
Los registros están en secuencia de forma lógica basados en los datos del índice, de modo 
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PEDIDO 




Cuando la relación es: m'uc.hos : 
a muchos, se necesitan tres 
archivos. 


que se agrupan todos los registros para el mismo NUMERO-PEDIDO. Para cada registro de 
ARTICULO DEL PEDIDO que hace coincidir el NUMERO-PEDIDO deseado, lea direc¬ 
tamente la tabla MAESTRO DE ARTÍCULOS usando NUMERO-ARTÍCULO como un 
índice. 

La lógica es la misma para una situación inversa, tal como encontrar todos los pedidos pa¬ 
ra un artículo de una nueva orden de pedido que se ha recibido. Use el NUMERO-ARTÍCU¬ 
LO deseado para leer directamente la tabla ARTÍCULO-PEDIDO. El índice de ARTÍCULO 
DEL PEDIDO se establece para el NÚMERO-ARTÍCULO. Para todos los registros de coinci¬ 
dencia de ARTÍCULO DEL PEDIDO, use el NUMERO-PEDIDO para leer directamente 
la tabla PEDIDO. Finalmente, lea directamente la tabla MAESTRO DE CLIENTES para 
obtener el NOMBRE-CLIENTE y la DIRECCIÓN usando el NÚMERO-CLIENTE en 
la tabla PEDIDO. 


LINEAM ENTOS 1 2 3 ARAELf SEÑO DE RELACIÓN ARCHIVO 
MAESTRO/BASE DE DATOS 


Al diseñar relaciones de archivos maestros o bases de datos se deben tomar en cuenta los 
siguientes lincamientos: 


1. Cada entidad de datos separada debe crear una tabla maestra de base de datos. No 
combine dos entidades distintas en un archivo. Por ejemplo, los artículos se compran de 
los vendedores. La tabla MAESTRO DE ARTÍCULOS sólo debe contener información 
del artículo y la tabla MAESTRO DE VENDEDORES sólo debe contener informa¬ 
ción del vendedor. La figura 13.27 ilustra el diccionario de datos para las tablas MAESTRO 
DE ARTÍCULOS y MAESTRO DE VENDEDORES. 

2. Un campo de datos específico sólo debe existir en una tabla maestra. Por ejemplo, el 
NOMBRE DEL CLIENTE sólo debe existir en la tabla MAESTRO DE CLIENTES, no 
en la tabla PEDIDO o en cualquier otra tabla maestra. Las excepciones a este lincamien¬ 
to son la clave o los campos de índice, los cuales podrían estar en tantas tablas como sea 
necesario. Si un informe o pantalla necesita información de muchas tablas, los índices 
deben proporcionar la vinculación para obtener los registros necesarios. 

3. Cada tabla maestra o relación de la base de datos debe tener programas para Crear, 
Leer, Actualizar y Eliminar (abreviado CLAE] los registros. En teoría, un solo programa 
debe agregar nuevos registros y un solo programa debe eliminar registros específicos. 
Sin embargo, muchos programas podrían ser responsables de cambiar campos de datos 
en el curso de actividades normales del negocio. Por ejemplo, un archivo MAESTRO 
DE CLIENTES podría tener un campo SALDO ACTUAL que se incrementa por el 
TOTAL PEDIDO en el programa de procesamiento del pedido y disminuye por una 
CANTIDAD A PAGAR o una CANTIDAD DEVUELTA de dos programas adicionales. 


DISEÑO DE BASES DE DATOS 













Archivos maestros aei aracuio 
mejorado y del vendedor. 





RESTRICCIONES DE INTEGRIDAD 

Las restricciones de integridad son reglas que controlan el cambio y eliminación de registros, 
y ayuda a mantener los datos en la base de datos exacta. En una base de datos se aplican 
tres tipos de restricciones de integridad: 

1. Integridad de identidad. 

2. Integridad referencial. 

3. Integridad de dominio. 


Las restricciones de integridad son reglas que controlan la composición de reglas princi¬ 
pales. La clave primaria no puede tener un valor nulo, y si la clave primaria es una clave 
compuesta, ninguno de los campos de componente en la clave puede contener un valor 
nulo. Algunas bases de datos le permiten definir una restricción única o una clave única. 
Esta última identifica un solo registro, el cual no es una clave primaria. La diferencia en¬ 
tre una clave única y una clave primaria, es que la primera podría tener un valor nulo. 

La integridad referencial controla la naturaleza de los registros en una relación uno a 
muchos. La tabla que se conecta en el extremo uno de la relación se llama padre. La tabla 
que se conecta en el extremo muchos de la relación se llama tabla hija. La integridad refe¬ 
rencial significa que todas las claves externas de la tabla muchos (la tabla hija) deben tener 
un registro de coincidencia en la tabla padre. Por lo tanto, no puede agregar un registro en la 
tabla (muchos) hija sin un registro de coincidencia en la tabla padre. 

Una segunda implicación es que no puede cambiar una clave primaria que tiene regis¬ 
tros de coincidencia de la tabla hija. Si pudiera cambiar el registro padre, el resultado sería 
un registro hijo que tendría un registro padre diferente o un registro huérfano, o un registro 
hijo sin un registro padre. Los ejemplos son un registro de CALIFICACIONES para un es¬ 
tudiante que no estaría en la tabla MAESTRO DE ESTUDIANTES y un registro de PEDIDO 
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para un NÚMERO DEL CLIENTE que no existió. La última implicación de la integridad 
referencial es que no puede eliminar un registro padre que tenga registros hijos. Esto tam¬ 
bién se aplicaría para los registros huérfanos mencionados anteriormente. 

La integridad referencial se implementa de dos formas diferentes. Una forma es tener 
una base de datos restringida, en la cual el sistema pueda actualizar o eliminar un registro 
padre sólo si no hay registros hijos de coincidencia. Una base de datos en cascada eliminará 
o actualizará todos los registros hijos al eliminar o cambiar un registro padre [el padre acti¬ 
va los cambios). 

Una relación restringida es buena cuando se cambian los registros. [No querría elimi¬ 
nar un registro del cliente ni tampoco todas las facturas a pagar! El enfoque en cascada 
es mejor cuando se cambian los registros. Si se cambia la clave primaria de un registro 
del estudiante, también se deben cambiar las claves externas de todos los registros del 
curso para dicho estudiante (el NUMERO DEL ESTUDIANTE en el MAESTRO DE 
CURSOS). 

Las reglas de integridad de dominio se usan para validar los datos, tales como la tabla, 
límite, rango y otras marcas de validación. Estos se explican con mayor detalle en el capítulo 
15. Normalmente las reglas de integridad de dominio se almacenan en la estructura de base 
de datos de una o dos formas. Las restricciones de verificación se definen en el nivel de la ta¬ 
bla y pueden consultar uno o más campos en la tabla. Un ejemplo es que la FECHA DE LA 
COMPRA siempre es menor o igual a la fecha actual. Las reglas se definen al nivel de la base 
de datos como objetos separados y se pueden usar con varios campos. Un ejemplo es un valor 
que es mayor a cero, usado para validar varios elementos. 


USO DE LA BASE DE DATOS 

Hay varios pasos que deben seguir un orden secuencial para asegurar que la base de datos 
será útil para presentar los datos. 


PASOS EN LA RECUPERACIÓN Y PRESENTACIÓN DE DATOS 

Hay ocho pasos en la recuperación y presentación de datos: 

1. Escoja una relación de la base de datos. 

2. Una dos relaciones. 

3. Proyecte las columnas de la relación. 

4. Seleccione filas de la relación. 

5. Derive nuevos atributos. 

6. Indexe o clasifique las filas. 

7. Calcule los totales y medidas de desempeño. 

8. Presente los datos. 

El primer y último pasos son obligatorios, pero los seis pasos intermedios son opcionales, 
dependiendo de cómo se usen los datos. La figura 13.28 es una guía visual para los pasos 
que se describen en las siguientes subsecciones. 

Escoja una relación de la base de datos El primer y obvio paso es escoger una relación de 
la base de datos. Una buena forma de realizar este paso es llevar un directorio de las vistas 
de usuario como auxiliar para su memoria. Aun cuando el usuario quiere una consulta ad 
hoc,es útil tener disponibles vistas similares. 
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Los datos se recuperan y presentan 
en ocho pasos distintos. 



Escoja una(s) relación(es) 
de la base de datos. 


Agrupe las relaciones. 


Proyecte las columnas 
de la relación. 


Seleccione filas 
de la relación. 




Indexe o clasifique las filas. 


Calcule los totales y las 
medidas de desempeño. 




Agrupe dos relaciones La acción de unir se piensa como tomar dos relaciones y agruparlas 
para hacer una relación más grande. Para que dos relaciones se unan, deben tener un atributo 
en común. Por ejemplo, tome dos relaciones de nuestro ejercicio: 


CLIENTE 


[NÚMERO-CLIENTE. NOMBRE-CLIENTE, 
MJMERQrALMACÉNJ 


ALMACEN (NUMERO-ALMACEN. 

UBICACIÓN-ALMACÉN) 
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CLIENTE 


NÚMERO 

CUENTE 

NOMBRE 

CUENTE 

NÚMERO 

ALMACÉN 

18765 

Delta Systems 


18830 

A. Levy and Sons 

3 ", 

19242 

RamerCompany 

3. ; 

18841 

; r :: vy?. Flood; IncJ í ;;: 1 

h;:2;:A 

18899 

Seward Systems 

2 . Ú 

19565 

StodolasUnc 

”‘Úé:' : ;'.Í.ÚÍa 

etc. 




ALMACEN 



NÚMERO 

ALMACÉN 

UBICACIÓN 

ALMACÉN 

... " i, •; - 1 

Fargo 

;';3U> 

Bismarck 

2 - ■ \ 

Superior 

1 

Plymouth 

etc. 1 



NÚMERO 

CLIENTE 

NOMBRE 

CUENTE 

NÚMERO 

ALMACÉN 

UBICACIÓN 

ALMACÉN 

18765 

Delta Systems 

.; 4 

Fargo 

.18830 

A. Levy and Sons 

'• ,,,r 

Bismarck 

■19242 . 

RamerCompany 

' 3 

Bismarck 

18841 

R. W. Flood Inc.' 


Superior 

18899.. 

Seward Systems 


Superior 

19565 ' 

Stodola's. Inc. 


Plymouth 

etc. 






La operación de unir toma dos 
relaciones y las agrupa para 
formar una sola relación. 


Suponga que unimos estas relaciones al NÚMERO-ALMACÉN para obtener una nueva rela¬ 
ción, el CLIENTE-ALMACÉN-UBICACIÓN. En la figura 13.29 se ilustra la unión de estas 
relaciones. También observe que la nueva relación no es 3NF. 

La acción de unir también podría ir un paso más allá; es decir, podría combinar los ar¬ 
chivos para las filas que tienen un atributo que se encuentra en una cierta condición. La 
figura 13.30 muestra un ejemplo en el cual dos relaciones, VENTAS y CUOTA, se unen 
para satisfacer la condición que se ha encontrado un vendedor o ha excedido las cuotas 
predeterminadas. 

La acción de unir-es importante porque puede tomar muchas relaciones 3NF y combi¬ 
narlas para hacer una relación más útil. Junto con las acciones de abajo, unir es una acción 
poderosa. 

Proyecte las columnas de la relación Proyección es el proceso de construir una relación 
más pequeña escogiendo únicamente atributos relevantes de una relación existente. En 
otras palabras, proyección es la extracción de ciertas columnas de una tabla relacional. 

En la figura 13.31 se presenta un ejemplo de proyección. La relación 


CLIENTE-ALMACÉN-UBICACIÓN ( NUMERO-CLIENTE. 

NOMBRE-CLIENTE, 
NÚMERO-ALMACÉN), 
ÜB ÍCACÍÓN-ALMACÉN 













se proyecta en NÚMERO-CLIENTE y UBICACIÓN-ALMACÉN, y durante el proceso de 
la proyección, se remueven los registros duplicados. 

Selección de filas de la relación La acción denominada selección es parecida a la proyec¬ 
ción, pero en lugar de extraer las columnas, extrae las filas. La selección crea una relación 
(más pequeña) nueva mediante la extracción de registros que contienen un atributo que 
coincide con una cierta condición. 

La figura 13.32 muestra cómo funciona la acción de selección. La selección se de¬ 
sempeña en la relación PERSONAL para extraer sólo a los empleados asalariados. Aquí no 
es necesario remover los registros duplicados, como se hizo en el ejemplo anterior de la 
proyección. 

La selección también se podría desempeñar para un juego más complejo de condicio¬ 
nes, tal como seleccionar a todos los empleados que están asalariados y que ganan más de 
$40,000 al año, o seleccionar empleados a quienes se les paga por hora y que ganan más 
de $15.00 por hora. La selección es una acción importante para las consultas ad hoc. 

Derive nuevos atributos El quinto paso involucra la manipulación de los datos existentes 
además de algunos parámetros adicionales (si son necesarios) para derivar los nuevos datos. 
Se crean nuevas columnas para la relación resultante. En la figura 13.33 se puede encontrar 
un ejemplo de la derivación de nuevos atributos. Aquí, se determinan dos atributos nuevos: 
(1) CIRCUNLERENCIA (multiplicar la suma de ancho y alto por 2 y agregarlo a la longitud) 
y (2) PESO-ENVÍO (el cual depende de la circunferencia). 
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La proyección crea una relación 
pequeña al seleccionar sólo 
atributos relevantes (columnas) 


de la relación. 


Indexación o clasificación de las filas Las personas necesitan que los datos se organicen en 
un cierto orden de modo que puedan localizar los artículos con mayor facilidad en una lis¬ 
ta o un grupo y que puedan calcular subtotales más fácil. Están disponibles dos opciones pa¬ 
ra ordenar datos: indexación y clasificación. 

La indexación es el orden lógico de las filas en una relación de acuerdo con alguna cla¬ 
ve. Como se discutió en la sección anterior, el indicador lógico ocupa espacio, y listar la re¬ 
lación usando un índice es más lento que si la relación estuviera en el orden físico apropia¬ 
do. Sin embargo, el índice ocupa mucho menos espacio que un archivo duplicado. 

La clasificación es el orden lógico de una relación. El resultado de una clasificación físi¬ 
ca es un archivo secuencial como se discutió en el capítulo anterior. La figura 13.34 ilustra la 
indexación y clasificación de la relación PERSONAL por el nombre del empleado en orden 
alfabético. 

Cálculo de los totales y de las medidas de desempeño Una vez que se define el subcon¬ 
junto de datos apropiado y que las filas de la relación se ordenan de la forma requerida, se 
pueden calcular los totales y medidas de desempeño. La figura 13.35 muestra cómo se realiza 
el cálculo. 

Presentación de los datos al usuario El último paso en la recuperación de datos es la pre¬ 
sentación. La presentación de los datos abstraídos de la base de datos pude tomar muchas 
formas. Algunas veces los datos se presentarán en forma tabular, algunas veces en gráficos y 
otras como una respuesta de una sola palabra en una pantalla. El diseño de salida, como se 
trató en el capítulo 11, proporciona una apariencia más detallada en cuanto a los objetivos 
de la presentación, formularios y métodos. 








DESNORiALIZACIÓN 

Una de las razones principales para la normalización es organizar los datos para reducir los 
datos redundantes. Si no se le pide almacenar los mismos datos una y otra vez, puede aho¬ 
rrar mucho espacio. Dicha organización permite al analista reducir la cantidad necesaria de 
almacenamiento, algo muy importante cuando el almacenamiento era caro. 

En la última sección aprendimos que para usar los datos normalizados teníamos que 
progresar en una serie de pasos que involucra unir, clasificar y resumir. Cuando acelera la 
consulta de base de datos (es decir, hacer una pregunta y requerir una respuesta rápida) es 
critico, podría ser importante almacenar los datos de otras formas. 

La desnormalización es el proceso de tomar el modelo de datos lógicos y transformarlo 
en un modelo físico que es eficaz para las tareas más comunes. Estas tareas pueden incluir 
generación de informes, pero también pueden significar consultas más eficaces. Las consul¬ 
tas complejas tales como el proceso analítico en línea (OLAP), así como también la minería 
de datos y los procesos de descubrimiento de datos del conocimiento (KDD), también pueden 
usar las bases de datos denormalizadas. 

La desnormalización se puede lograr de varias formas diferentes. La figura 13.36 descri¬ 
be algunos de estos enfoques. Primero, podemos tomar una relación muchos a muchos, tal 
como el de VENDEDOR y CLIENTE, la cual comparte las entidades asociativas de VENTAS. 
Al combinar los atributos de VENDEDOR y VENTAS podemos evitar uno de los procesos 
de la unión. Esto podría producir una cantidad considerable de duplicidad de datos, pero 
hace las consultas sobre los modelos de las ventas más eficaz. 

Otra razón para la desnormalización es evitar la referencia repetida para una tabla de 
búsqueda. Podría ser más eficaz repetir la misma información —por ejemplo, la ciudad, el es- 



ASPECTOS ESENCIALES DEL DISEÑO 










INFORMACIÓN-PAQUETE 


NÚMERO 

PAQUETE 

ANCHO 

ALTO 

TAMAÑO 

PESO 

;! A3456 


_3> : 

•26 

4 

A3457. 1 


LT2 ; ;Tj 

20 

10 

A3458 

10 

20 

34 

20 

A3459 

15 

15. 

22 

A 18 

A3460 

; v : : 1CL ; 

: toa 

.40 

40 

A3461 

AJÓ!-;- 

20 

34 

22 

A3462 

' y : 5 !=• 

10 

15 

30 

A3463 

8 

14 

44 

35 


CIRCUNFERENCIA = 2 (ANCHO + ALTO) 
+ TAMAÑO 


INFORMACIÓN-ENVIO-PAQUETE 



SI CIRCUNFERENCIA > 84 Y PESO < 25 
ENTONCES PESO DE ENVIO = 25 
SE NO PESO DE ENVÍO = PESO 


NÚMERO 

PAQUETE 

ANCHO 

ALTO 

TAMAÑO 

PESO 

CIRCUNFE¬ 

RENCIA 

PESO 

ENVÍO 

A3456 

4 

3 

26 

4 

50 

V.:-4Á" 

A3457 

12 

I, 2 ; 

20 

10 

68 


A3458 

10 

20 

34 

20 

94 

25 

A3459 

15 

15 

22 

18 

82 

18 

A3460 

10 

10 

40 

40 

80 

40 

A3461 

10 

20 

: .34 ■ 

22: 

90 

25 

A3462 

. 5 

10 ■/. 

15 

30 

45 

30 : ■ 

A3463 

8 

14 

44 

35 

88 

35 



La derivación crea nuevos 
atributos (columnas) en la 
relación al manipular los 
datos contenidos en atributos 
existentes. 


tado y el código postal— aun cuando esta información normalmente se puede almacenar 
sólo como un código postal. Por lo tanto, en el ejemplo de las ventas, se podrían combinar 
CLIENTE y ALMACÉN. 

Finalmente, veremos relaciones uno a uno porque es muy probable que se combinen 
por razones prácticas. Si entendemos que muchas de las consultas con respecto a los pedi¬ 
dos también se interesan en cómo fue enviado el pedido, tendría sentido para combinar, 
o denormalizarse. Por lo tanto, en el ejemplo, algunos de los detalles pueden aparecer en 
DETALLES-PEDIDO y DETALLES-ENVÍO cuando vemos la desnormalización. 


ALMACENES DE DATOS 

Los almacenes de datos difieren de las bases de datos tradicionales. El propósito de un al¬ 
macén de datos es organizar la información para consultas rápidas y eficaces. De hecho, 
almacenan datos denormalizados, pero van un paso más adelante. Dichos almacenes or¬ 
ganizan los datos en torno a los temas. En la mayoría de los casos, un almacén de datos es 
más que una base de datos procesada de manera que los datos se representen de formas 
uniformes. Por consiguiente, los datos almacenados en los almacenes de datos provienen 
de diferentes fuentes, normalmente de bases de datos que se establecen para diferentes 
propósitos. 


DISEÑO DE BASES DE DATOS 

















La operación oraena ios 
pedidos de los registros (filas) 
en la relación de manera que los 
registros se puedan desplegar 
en orden y se puedan agrupar 
por los subtotales. Aquí la 
relación PERSONAL se ordena 
alfabéticamente de acuerdo con 
el NOMBRE DEL EMPLEADO. 



El concepto de almacén de datos es único. Las diferencias entre los almacenes de datos 
y las bases de datos tradicionales incluyen lo siguiente: 

1. En un almacén de datos, los datos se organizan en torno a los temas principales en lu¬ 
gar de transacciones individuales. 

2. En un almacén de datos los datos normalmente se almacenan como datos resumidos en 
lugar de detallados, los datos básicos se encuentran en una base de datos de transacciones. 

3. En un almacén de datos los datos cubren un periodo más largo que los datos en una base 
de datos tradicional orientada a transacciones porque las consultas normalmente involu¬ 
cran toma de decisiones a largo plazo en lugar de los detalles de transacción diarios. 

4. La mayoría de los almacenes de datos se organizan para consultas más rápidas, mientras 
que las bases de datos más tradicionales se normalizan y estructruan de tal manera que 
proporcionen almacenamiento eficaz de información. 

5. Los almacenes de datos normalmente se optimizan para responder consultas complejas, 
conocidas como OLAP, de gerentes y analistas, en lugar de consultas hechas de forma 
simple y repetida. 

6. Los almacenes de datos permiten acceso fácil mediante software de minería de datos 
(denominado siftware) que busca modelos y puede identificar relaciones no imagina¬ 
das por los tomadores de decisiones humanos. 

7. Los almacenes de datos no incluyen una sola sino muchas bases de datos que se han 
procesado para que los datos del almacén se definan uniformemente. Estas bases de datos 
se denominan datos limpios. 

8. Los almacenes de datos normalmente incluyen datos de fuentes externas (tales como 
un informe de industria, los reportes de la empresa para el Gobierno o incluso la infor¬ 
mación acerca de los productos de competidores), así como también generaron datos 
para uso interno. 
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Algunos ejemplos: 


1 

Cálculo | 


597 

187 í 


Número de paquetes que pesaron menos de 25 
libras pero que fueron enviados a una tasa de 25 libras 


Número total de paquetes enviados ■ 


Porcentaje de paquetes que pesaron menos de 2¿> 
libras pero que fueron enviados a una tasa de 25 libras" 



El cálculo proporciona los 
subtotales, totales y otras 
medidas de desempeño. 


Construir un almacén de datos es una gran tarea. El analista necesita recopilar los datos de 
una variedad de fuentes y convertirlos a una forma común. Por ejemplo, una base de datos 
podría almacenar información acerca del género como "Masculino" y "Femenino", otra la po¬ 
dría almacenar como "M" y "F" y una tercera la podría almacenar como " 1" y "0". El analista 
necesita establecer un estándar y convertir todos los datos al mismo formato. 

Una vez que los datos estén limpios, el analista debe decidir cómo resumirlos. Una vez 
resumidos, se pierden los detalles, de manera que un analista tiene que predecir el tipo de 
consultas que se podrían hacer. 

Después, el analista necesita diseñar el almacén de datos con una organización lógica, y 
quizás incluso una agrupación física, de los datos por tema. Esto requiere mucho análisis 
y diseño. El analista necesita conocer bastante sobre el negocio. 

Los típicos almacenes de datos tienden a medir desde 50 gigabytes hasta decenas de te- 
rabytes. Debido a que son grandes, también son caros. La mayoría de los almacenes de datos 
cuestan millones de dólares. 


PROCESAMIENTO ANALÍTICO EN LÍNEA 

Introducido por primera vez en 1993 por E. F. Codd, el procesamiento analítico en línea 
[OLAP) se diseñó para responder a las consultas complejas de los tomadores de decisio¬ 
nes. Codd concluyó que un tomador de decisiones debía ver los datos de diferentes for¬ 
mas. Por lo tanto, la base de datos en sí tenía que ser multidimensional. Muchas personas 
describen a OLAP como el cubo de Rubik de datos. Puede ver los datos desde todos los 
diferentes lados y también los puede manipular torciéndolos o rotándolos para que tengan 
sentido. 
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Este enfoque de OLAP validó el concepto de almacenes de datos. Ahora tenía sentido 
que los datos se organziaran de formas que permitieran consultas eficaces. Por supuesto, 
OLAP abarca el procesamiento de datos mediante la manipulación, resumen y cálculo, pa¬ 
ra que se abarque más de un almacén de datos. 


MINERÍA DE DATOS 

La minería de datos puede identificar modelos que un humano no puede. Ya sea que el 
tomador de decisones no pueda visualizar un patrón, o quizás no se le ocurre preguntar si 
ese patrón existe. Los algoritmos de minería de datos buscan patrones en almacenes de 
datos siguiendo ciertos algoritmos. 

La minería de datos se conoce con otro nombre, descubrimiento de datos del conoci¬ 
miento (KDD o Knowledge Data Discovery). Algunos piensan que KDD difiere de la minería 
de datos porque el propósito de KDD es ayudar a los tomadores de decisiones a encontrar 
los modelos en lugar de pasar el control a un algoritmo para que los encuentre. Las herra¬ 
mientas disponibles para ayudar en la toma de decisiones se denominan siftware; incluyen 
análisis estadístico, árboles de decisión, redes neurales, agentes inteligentes, lógica difusa y vi- 
sualización de datos. 

Los tipos de patrones que los tomadores de decisiones intentan identificar incluyen 
asociaciones, secuencias, agrupamientos y tendencias. Las asociaciones son modelos que 
ocurren al mismo tiempo. Por ejemplo, una persona que compra cereal normalmente 
compra leche para acompañar el cereal. Por otro lado, las sucesiones son modelos de ac¬ 
ciones que tienen lugar durante un periodo. Por ejemplo, si una familia compra una casa 
este año, probablemente comprarán muebles (un refrigerador o lavadora y secadora] el 
próximo año. El agrupamiento es el modelo que se desarrolla entre un grupo de personas. 
Por ejemplo, clientes que tienen un código postal particular podrían tender a comprar un 
automóvil particular. Finalmente, las tendencias son modelos que se observan durante un pe¬ 
riodo. Por ejemplo, los clientes podrían cambiar de comprar bienes genéricos a productos 
de marca. 

En el capítulo 14 se trata con mayor detalle la minería de datos, junto con las consultas 
en general. 


PUBLICACIÓN DE BASES DE DATOS PARA WEB 

Todas las bases de datos que se basan en la Web son para compartir información. Por ejem¬ 
plo, puede establecer un sistema de administración de ventas y de inventario que permita a 
los empleados remotamente vista, edición y actualización de pedidos. Puede desarrollar las 
aplicaciones de administración de tarea para la Web que permita a los empleados asignar ta¬ 
reas o proyectos de búsqueda. 

También es posible establecer una tienda en línea que permite a clientes navegar en 
una base de datos de productos y hacer compras. Incluso es posible personalizar aplicacio¬ 
nes Web que usen páginas dinámicas con el contenido personalizado basado en intereses 
que el cliente introduce. 

El ejemplo presentado en la figura 13.37 ilustra cómo establecer un directorio de em¬ 
pleados en línea. Cualquier persona que visite el sitio Web puede buscar un empleado para 
localizar una extensión telefónica correcta. El ejemplo muestra una pantalla dividida con el 
código fuente en la parte superior y una representación visual de la página Web en la parte 
inferior de la pantalla. El ejemplo se generó usando Macromedia Dreamweaver UltraDev 4. 

Macromedia Dreamweaver UltraDev es un paquete de software de avanzado para el 
desarrollo de sitios de comercio electrónico. UltraDev se enfoca en la publicación de bases 
de datos para Web y apoya el lenguaje de marcado extensible (XML). 

UltraDev se orienta visualmente en lugar de orientarse hacia la edición de código fuen¬ 
te. Por lo tanto, el diseñador puede dibujar celdas de tabla directamente en una página, 
arrastrar celdas de otras ubicaciones o agruparlas para crear una tabla anidada. UltraDev 


DISEÑO DE BASES DE DATO? 





pantalla ¿e diseño de 
Macromedia Dreamweaver 
UltraDev4 usada para publicar 
en Web una base de datos 
de directorio del empleados. 


■ file: Edil: :.Yiew¡: 

Inserí 

Modify Jext _£ornmands _¡¡,g Wmde j JHUn. 

■ illSIlll 

P?:.AuíoréJresh; 

hiip iilocalhost}udpr 9 rsicompleled emplqilee fk.f£p?| 

Scttingü.. | 

;k(HM 

f ->' 

¿V 

! 7 Tüle: ¡ Emplojiees . • 

1 

317 .! 7 'td elass 

sis] <td elass 

319 - td elass 

= "username":-Name</td> 

="us erñame">Department </t d> 

= "username">ExTension</td;- 

i 


320 --/tr> 

321 ij <% while ((Repeatl_numRows— != 0) && (lemp.EOF)) { %> 

322- s-'tr bgcolor =''#-FFE7B5"> ^ 

323. -:td elass =''normaltext"x% = Cemp. Fields. item("LastÑame"), value)%>" 

324, ? <%=(emp.Fields.ítem("FirstMame").Value)%> I 


Employee Directo 



Department 


{Extensión 


¿©ates..Chri.sl jjOperatjqns.•;._.;3476. i 

yCanvass* Rob ;TnpStaff 'I346C : : : 

SDayiSj,Wejan.í-pperatipns ...13459.!: 1 

y Day.is, Betii, lÁccounting .• 1.112345.,.j- [ 

ijPuran'C.hris..jíripstaff.j;34p¿. 


_.,J__TGalla gher . Dav id.. [f.ripStaff. . 




1:3457 


‘ <t>;d|ixtabtPí cír'xld:. itoim> -tíabls> ,.smir_iep»Á(M(li»5lnftS.^<U> <t'[574>!05 r ¡ ,74KI2 I sfo c 




también permite al diseñador trabajar con datos vivos, páginas y lógica que se puede seguir 
usando mientras se trabaja con los datos del servidor. UltraDev permite a diseñadores crear 
rápidamente las aplicaciones Web manejadas con bases de datos para las múltiples platafor¬ 
mas de servidores. 

La figura 13.38 muestra cómo establecer un formulario que permite a un usuario insertar 
un registro en una base de datos. Por supuesto, también necesita establecer las restricciones 
de seguridad para que los usuarios primero introduzcan una contraseña, y se apruebe, antes de 
que puedan modificar la base de datos. UltraDev se puede usar para crear aplicaciones 
de páginas activas de servidor (ASP), aplicaciones ColdFusion (CF) o aplicaciones de Java- 
ServerPagesfJSP). 

XML, un estándar no patentado, proporciona el mecanismo para tomar los datos básicos 
y traducirlos a un lenguaje universal que se puede leer por cualquiera con las herramientas de 
traducción adecuadas. Muchas compañías están usando XML para mejorar el intecambio 
de datos electrónicos y para mejorar aún más la experiencia de Web para clientes. XML 
hace posible que los datos se entreguen por Internet, compartan y presenten de la mejor 
forma posible. 

Muchos paquetes de software están disponible para permitir la publicación de bases de 
datos en la Web mediante el uso de XML. Un ejemplo para las computadoras personales es 
FileMaker Pro, por FileMaker, Inc. es fácil integrar XML con FileMaker Pro mediante los 
formularios y hojas de estilo. FileMaker Pro recibe datos de una persona que usa un formu¬ 
lario HTML estándar y envía una respuesta en XML que incluye los datos y detalles acerca 
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E CONSULTORIA 13.2 


ALMACENAMIENTO DE MINERALES PARA 
LA SALUD,.DATOS PARA LA MINER 


Uno de los empleados de Marathón Vltamln Shops, Esther See, se 
acerca al propietario, Bill Berry, para hacerle una observación. "Me he 
percatado de que nuestros clientes tienen diferentes hábitos. Algunos 
vienen de manera regular y otros son menos predecibles", dice Esther. 
"Cuando veo a un cliente habitual, me enorgullezco de saberlo.que el 
cliente comprará e incluso tal vez le recomiendo otras vitaminas que po¬ 
drían gustarle. Creo que de esta manera genero más ventas. También, el 
cliente se siente mejor." 

Esther continúa: "Sin embargo, quisiera poder ayudar a algunos 
clientes que vienen con menos frecuencia". . 

"Ésa es una actitud muy positiva, Esther, y también es de mucha 
ayuda para nuestra tienda", responda Bill.; "Sé que nos podemos benefi¬ 
ciaren otros sentidos, si comprendemos los patrones de conducta de los 
clientes. Por ejemplo, podemos asegurarnos de contar con un artículo 
específico." . 


Esther asiente y agrega: "No sólo me refiero al tipo de vitamina. Al¬ 
gunos clientes prefieren una marca en vez de otra. No sé si esto dependa 
de sus ingresos o del Interés que tengan en determinadas actividades de 
esparcimiento. Por ejemplo, los deportes". 

"Entiendo, señorita See, ¿pero tiene alguna idea?" 

"Sí, señor Berry", responde ella. "Deberíamos organizar los datos que 
tenemos sobre nuestros clientes utilizando un almacén de datos. Pode¬ 
mos combinar nuestros datos con datos de otras fuentes. A continuación 
podemos buscar patrones en nuestros datos. Quizá podamos identificar 
patrones existentes y predecir nuevas tendencias." 

Piense de qué manera podría organizar un almacén de datos para: 
Marathón Vitamin Shops. ¿Qué otras bases de datos le gustaría combi¬ 
nar en. el almacén de datos? '¿Qué tipo de patrones debe buscar Bill 
Berry? Identifique estos patrones por tipo (asociaciones, secuencias, 
agrupamientos o tendencias). 


de dónde se puede encotrar una hoja de estilo para los datos. Proporcionar una hoja de esti¬ 
lo diferente o un programa de JavaScript puede mostrar una vista diferente de los mismos 
datos a cada usuario. De esta forma, los usuarios que prefieren un estilo de presentación a 
otro reciben lo que realmente quieren. 
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(INTRODUCIR REGISTRO) de 
Macromedia Dreamweaver 
UltraDev 4 usado para permitir a 
usuarios modificar remotamente 
los registros de la base de datos. 











































RESUMEN 


Con frecuencia, la forma de almacenar datos es una decisión importante en el diseño de un 
sistema de información. Hay dos enfoques para almacenar datos. El primero es almacenar¬ 
los en archivos individuales, un archivo para cada aplicación. El segundo enfoque es desa¬ 
rrollar una base de datos que se pueda compartir por muchos usuarios para una variedad 
de aplicaciones conforme sea necesario. Ha habido mejoras impresionantes en el diseño de 
software de bases de datos para tomar ventaja de las posibilidades que ofrecen las interfa¬ 
ces gráficas. 

El enfoque de archivo convencional a veces podría ser más eficaz, debido a que el archivo 
puede ser específico de una aplicación. Por otro lado, el enfoque de base de datos podría ser 
más apropiado porque los mismo datos necesitan ser introducidos, almacenados y actualizados 
una sola vez. 

Una comprensión del almacenamiento de datos requiere entender tres dominios: realidad, 
datos y metadatos. Una entidad es cualquier objeto o evento para el cual estamos deseosos re¬ 
copilar y almacenar datos. Los atributos son las características reales de estas entidades. Los 
datos pueden tener valores y se pueden organizar en los registros que se pueden acceder 
mediante una clave. Los metadatos describen los datos y pueden contener restricciones sobre 
el valor de los datos (como numérico). 

Los ejemplos de archivos convencionales incluyen archivos maestros, archivos de tabla, 
archivos de transacción, archivos de trabajo y archivos de informe. Pueden tener una orga¬ 
nización secuencial, listas enlazadas u organización de archivos hash. Las bases de datos se 
construyen típicamente con una estructura relacional. Sin embargo, los sistemas heredados 
pueden tener estructuras jerárquicas o de red. 

La normalización es el proceso que toma vistas de usuario y las transforma en estructuras 
menos complejas llamadas relaciones normalizadas. Hay tres pasos en el proceso de normali¬ 
zación. Primero, se remueven todos los grupos repetitivos. Segundo, se eliminan todas las 
dependencias parciales. Linalmente, se remueven las dependencias transitivas. Después que 
se completen estos tres pasos, el resultado es la creación de varias relaciones en tercera forma 
normal (3NL). 

El diagrama entidad-relación se podría usar para determinar las claves necesarias para 
un registro o una relación de base de datos. Los tres lincamientos a seguir al diseñar ta¬ 
blas maestras o relaciones de base de datos son que (1) cada entidad de datos separada 
debe crear una tabla maestra (no combine dos entidades distintas en una tabla); (2) un 
campo de datos específicos debe existir únicamente en una tabla maestra, y (3) cada tabla 
maestra o relación de base de datos debe tener programas para Crear, Leer, Actualizar y 
Elimnar. 

El proceso de recuperación de datos podría incluir hasta ocho pasos: (1) se escogen una re¬ 
lación o relaciones y (2) se unen; (3) la proyección y (4) la selección se realizan en la relación 
para extraer las filas y columnas relevantes; (5) se podrían derivar nuevos atributos; (6) las filas 
se clasifican o indexan; (7) se calculan los totales y medidas de desempeño y, finalmente, (8) los 
resultados se presentan al usuario. 

La desnormalización es un proceso que toma el modelo de datos lógico y lo transforma 
en un modelo físico que es eficaz para las tareas que son más necesarias. Los almacenes 
de datos difieren de las bases de datos tradicionales de muchas formas; una es que estas úl¬ 
timas almacenan datos desnormalizados, los cuales se organizan por temas. Los almacenes 
de datos permiten fácil acceso mediante software de minería de datos, denominado siftware, 
que busca los modelos e identifica las relaciones que los tamadores de decisiones humanos 
no imaginan. 

El Lenguaje de Marcado Extensible (XML) es un lenguaje estándar no patentado que 
sirve como un mecanismo para tomar los datos básicos y traducirlos a un lenguje universal 
que se puede leer por cualquiera con las herramientas de traducción adecuadas. Principal¬ 
mente se usa para el intercambio de datos de negocio. 
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"La gente de Sistemas de Administración me ha dicho cosas muy buenas de su equipo. Tam¬ 
bién se ha ganado algunos elogios de la gente de Capacitación, que difícilmente los hace. Ya 
sabe, es difícil complacer aTom Ketcham en estos días. Incluso él les ve algunas posibilidades. 
Creo que usted nos puede hacer jalar parejo... a menos que cada quienjale por su lado otra vez. 
Sólo estoy bromeando. Le dije que pensara si somos una familia, un zoológico o una zona de 
guerra. Ahora es el momento de que empiece a diseñar sistemas adecuados para nosotros. Us¬ 
ted lleva suficiente tiempo aquí para haberse formado sus propias opiniones. Espero que sean 
favorables. Creo que nuestra famosa hospitalidad sureña debió influir en usted, ¿no es verdad? 
Estuve tan ocupado tratando de persuadirlo de que vale la pena el esfuerzo que haga con no¬ 
sotros, que casi olvido decirle: Tom y Snowden están de acuerdo en considerar la posibilidad de 
adoptar algún tipo de base de datos. ¿Podría preparar algo durante las dos semanas siguientes? 
Tom se encuentra en una conferencia en Minneapolis, pero a su regreso usted debe tener algu¬ 
nas ideas sobre la base de datos para que Snowden y él las analicen. Concéntrese en ello". 


: msmmm ■ 

Si 


PREGUNTAS DE HYPERCASE ' 

1. Suponga que los miembros de su equipo han utilizado el Informe de Características de 
Clientes de la Unidad de Capacitación para diseñar una tabla de base de datos con el pro¬ 
pósito de almacenar la información importante de este informe, con el resultado siguiente: 
Nombre de la tabla: TABLA DE CLIENTES 


NOMBRE DE COLUMNA DESCRIPCION 


ID CUENTE (clave : Nemomco hecho pontos usuarios: como,-HSPEST para Hospital 

primaria).’ ■ >• Estatal; -. ¿aaava aa/aSía- íia 

NOMBRE DEL CUENTE • El nombre real y completo: del cliente 1 1 


NOMBRE DEL CUENTE El nombre real y completo del cliente 1 1 

DIRECCIÓN ", , La d recclón del cliente ■ 1 - . a.. 1 ' UP;' 

CONTACTO, V El nombro de ja persona; a contactar :: A -A 

NUMERO TELEFONICO . El número telefónico de-la persona-a: contactar 

tAAM: --ÁAA: ; ? ;" ;:AY A;': - :?:;: 1 : ,L - " - : : . 

CLASE . .. El tipo de institución (Hospital de Veteranos, clínica. 


P) A; f':; A:: A.;;:'y.A:;A.: 

Tamaño dpi personal del cliente 



I número de maquinas que tiene el cliente - , : - i,. 

!¡ •-.••r**:. •* vurfirv.. ,-. A <í'viWílgoJi 


2. Aplique normalización a la tabla que desarrolló su equipo para eliminar los grupos que 
se repitan. Muestre sus resultados. 

3. Elimine las dependencias transitivas de su tabla y muestre la tabla de base de datos que 
obtuvo. 


PALABRAS Y FRASES CLAVE 


administrador de base de datos 

archivo de informe 

almacén de datos 

archivo de tabla 

almacenamiento de datos 

archivo de trabajo 

archivo convencional 

archivo de transacciones 


□SENO DE BASES DE DATOS 


—rnm 










archivo maestro 
atributo 
base de datos 
caracteres especiales 
CLAE - Crear, Leer, Actualizar 
y Eliminar (CURD) 
clave 

clave concatenada 
clave primarla 
clave secundaria 
datos 

datos limpios 
dependencias parciales 
dependencias transitivas 
desnormalización 
diagrama de burbuja 
diagrama de modelo de datos 
diagrama entidad-relación (E-R) 
entidad 

estructura de datos de red 
estructura de datos jerárquica 
estructura de datos relacional 
grupo repetitivo 
integridad de dominio 
integridad referencial 
lenguaje de marcado extensible 
(XML) 

lista enlazada 
minería de datos 
normalización 

organización de un archivo hash 


pasos en la recuperación de información 
calcular 
derivar 
escoger 

¡ndexar o clasificar 

presentar 

proyectar 

seleccionar 

unir 

patrones 

agrupamiento 

asociaciones 

secuencias 

tendencias 

primera forma normal (INF) 

procesamiento analítico en línea (OLAP) 

realidad, datos y metadatos 

recuperación 

registro 

relación 

relación sin normalizar 
restricción de integridad de entidad 
segunda forma normal (2NF) 
slftware 

sistema de administración de base 
de datos (DBMS) 
subtipo de entidad 
tercera forma normal (3NF) 
vista física 
vista lógica 


PREGUNTAS DE REPASO 

1. ¿Cuáles son las ventajas de organizar el almacenamiento de datos como archivos se¬ 
parados? 

2. ¿Cuáles son las ventajas de organizar el almacenamiento de datos usando un enfoque 
de base de datos? 

3. ¿Cuáles son las medidas de efectividad del diseño de la base de datos? 

4. Mencione algunos ejemplos de entidades y sus atributos. 

5. Defina el término metadatos. ¿Cuál es el propósito de los metadatos? 

6. Mencione los tipos de archivos convencionales comúnmente usados. ¿De éstos cuáles 
son archivos temporales? 

7. ¿Qué es una lista enlazada? 

8. ¿Qué sucede con frecuencia cuando se usa la organización de un archivo hash? 

9. Mencione los tres tipos principales de organización de base de datos. 

10. Defina el término normalización. 

11. ¿Qué se remueve cuando una relación se convierte a la primera forma normal? 

12. ¿Qué se remueve cuando una relación se convierte de INF a 2NF? 

13. ¿Qué se remueve cuando una relación se convierte de 2NF a 3NF? 

14. Mencione las tres restricciones de una entidad. En una frase, describa el significado de 
cada restricción. 

15. Mencione los ocho pasos para recuperar, preclasificar y presentar los datos. 

16. ¿Qué hace una función de unión? ¿Qué es la proyección? ¿Qué es la selección? 
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17. Establezca las diferencias entre clasificar e indexar. 

18. Mencione dos formas de almacenar una relación muchos a muchos y las diferencias 
entre los dos métodos. 

19. Defina la desnormalización. 

20. Explique las diferencias entre las bases de datos tradicionales y los almacenes de datos. 

21. Defina lo que hace el siftware cuando se usa en la minería de datos. 

22. Explique cómo funciona XML para facilitar el intercambio de datos de negocio. 


PROBLEMAS 

1. Dado el siguiente archivo de arrendatarios: 


Caducidad 

Número Número de del arrenda- 


del registro 

Apellido 

departamento 

Renta 

miento 

41 

Warkentin 

102 

550 

430 

'L42; : u-v 

Buffington 

. .204'. 

'í 600 

4/30 

' ' 43/.U 

Schuldt 

. 103 

550 

.4/30 

44 ; j 

Tang 

'209 

600 

5 31 

45 

• Cho U' : ; 

. . 203 ' 

550 

5/31 / 

' 46 j \ 1 

Yoo 

. ..203v 

550 

6/30 . 

47 

Pyle 

101 

500 

•-V 6/30 


a. Desarrolle una lista enlazada por el número de departamento en orden ascendente. 

b. Desarrolle una lista enlazada según el apellido en orden ascendente. 

2. El siguiente ejemplo muestra un reporte de calificación para dos estudiantes en la Uni¬ 
versidad del sur de Nueva Jersey: 




Informe de calificación USNJ 





Semestre primavera 2000 



Nombre: 

1. M. Smarte 


Especialidad: MIS 

Estudiante: 053-6929-24 

Estado: Estud. de últ. grado 

Número 



Departamento 

Califl- 

del curso 

Título del curso 

Profesor 

del profesor 

cación 

MIS 

403 

Análisis de sistemas 

Diggs, T. 

MIS 

A 

MIS 

411 

Bases conceptuales 

Barre, G. 

MIS 

A' 

MIS 

420 

Factores humanos en IS 

Barre, G. 

MIS 

B 

CIS 

412 

Diseño de bases de datos 

Menzel, 1. 

CIS 

A 

DESC 

353 

Modelos de administración 

Murney, J. 

MIS 

A 



Informe de calificación USNJ 




Semestre primavera 2000 



Nombre: E.Z. Grayed 


Especialidad: MIS 

Estudiante: 472-6124-59 

Estado: Estud. de últ. grado 

Número 



Departamento 

Califi- 

del curso 

Título del curso 

Profesor 

del profesor 

cación 

MIS 403 

Análisis de sistemas 

Diggs, T. 



MIS 411 

_ 

Bases conceptuales 

Barre, G. 

__l 




3. Dibuje un diagrama de modelo de datos con asociaciones para la vista de usuario en el 
problema 2. 

4. Convierta la vista de usuario del problema 3 a una relación 3NF. Muestre cada paso en 
el proceso. 
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5. Dibuje un diagrama entidad-relación para la siguiente situación: muchos estudiantes 
practican muchos deportes diferentes. Una persona, llamada entrenador principal, 
asume el papel de entrenamiento en todos estos deportes. Cada una de las entidades 
tiene un número y un nombre. (Haga cualesquier suposiciones necesarias para comple¬ 
tar un diagrama razonable. Mencione sus suposiciones.] 

6. El diagrama entidad-relación que dibujó en el problema 5 representa las entidades de 
datos que se necesitan implementar en un sistema para llevar un registro de los estudian¬ 
tes y los equipos deportivos que practican. Mencione las tablas que el sistema necesita 
implementar, junto con las claves principal, secundaria y externa que se requieren para 
vincular las tablas. 

7. Dibuje un diagrama entidad-relación para la siguiente situación: una panadería comercial 
hace muchos productos diferentes. Estos productos incluyen panes, postres, pasteles es¬ 
peciales y muchos otros tipos de repostería. Los ingredientes tales como la harina, espe¬ 
cias y leche se compran a vendedores. A veces un ingrediente se compra de un solo 
vendedor y otras veces un ingrediente se compra de muchos vendedores. La panadería 
tiene clientes comerciales, tales como escuelas y restaurantes que regularmente hacen pedi¬ 
dos de pasteles. Cada pastel tiene un especialista que supervisa su proceso de producción 
e inspecciona el producto terminado. 

8. Mencione las tablas y claves que se necesitan para implementar el sistema de la panade¬ 
ría comercial. 

9. Dibuje un diagrama E-R para el sistema de pedidos de la figura 13.26. 

10. Dibuje un diagrama de flujo de datos para hacer un pedido. Base su diagrama de flujo 
de datos en el modelo E-R. 


PROYECTOS DE GRUPO 

1. Gregg Baker pide por Web boletos para dos conciertos. Sus pedidos se procesan, se les 
asigna un asiento único en el auditorio y los boletos se envían por correo por separado. 
Uno de los juegos de boletos se pierde en el correo. Cuando él llama al número de servi¬ 
cio, no recuerda la fecha o los números de asiento, pero la agencia del boleto pudo 
localizar sus boletos rápidamente porque la agencia desnormalizó la relación. Describa 
el sistema de pedido de boleto mencionando los elementos de datos que se llevan en el 
formulario de pedido y el formulario de envío. ¿Qué información tuvo que dar Gregg a 
la agencia del boleto para recuperar la información? 
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ALLEN SCHMIDT, JULIE E. KENDALL Y KENNETH E. KENDALL 

FUlOáiENTOS DE DITOS 



Después de haber terminado las numerosas entrevistas, prototipos, diagramas de flujo de 
datos y entradas del diccionario de datos, Anna y Chip comienzan a trabajar en el modelo 
entidad-relación. "Yo me encargaré de crear las relaciones de las tablas de Microsoft Access", 
promete Anna. Chip se ofrece a elaborar un diagrama de entidad-relación. "Comparemos 
la precisión y consistencia de los dos diagramas cuando terminemos", sugiere Anna, y así lo 
hacen. 

La figura E13.1 muestra el diagrama de entidad-relación para el sistema de inventario 
de computadoras. Visible Analyst denomina entidad a cada uno de los rectángulos. Cada en¬ 
tidad representa un archivo de información almacenado en el sistema, y corresponde a un 
almacén de datos en el diagrama de flujo de datos. Cada uno de los rectángulos con un dia¬ 
mante representa una relación entre las entidades de datos. Un rectángulo con un óvalo 
representa una entidad que no puede existir sin la entidad a la que se conecta, como una 
tabla de códigos. 

'Ya elaboré el diagrama de entidad-relación, empezando por las partes más simples del 
sistema". Chip le dice a Anna. "Las primeras entidades de datos creadas son SOFTWARE y 
COMPUTER. La relación consiste en que el software está instalado en la computadora. 
Luego determiné la cardinalidad de la relación. Puesto que un paquete de software podría ins¬ 
talarse en muchas computadoras, esta relación es uno-a-muchos. Cada computadora también 



contains 


¡nstalled on 



Hardware Inventory Number + 
Brand Ñame + 

Model + 

Serial Number + 

Date Purchased + 

Purchase Cost + 

Replacement Cost + 

Memory Slze + 

Hard Dlsk Capacity + 

Second Hard Dlsk Capacity + 
Floppy Drive + 

CD-ROM Drive + 

Zlp Drive + 

IMwork + 

NetWork Connection Ñame + 
Display Ñame + 

Printer Descriptlon + 

Warranty + 

Campus Descriptlon + 

Room Locatlon 
(Board Code] + 

(Software Inventory Number} 


Software Inventory Number + 
Tifie + 

Operatlng System Ñame + 
Versión Number + 

Publisher + 

Software Category Description + 
Number of Media + 

Computer Brand + 

Computer Model + 

Memory Required + 

Display Ñame + 

Printer Description + 

Type of Media + 

Site Ucense + 

Number of Copies + 

Expert Last Ñame + 

Expert First Ñame + 

Office Phone 



Diagrama de entidad-relación sin normalizar para el sistema de cómputo: • 
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puede tener muchos paquetes de software diferentes instalados, así que también presenta 
una relación uno-a-muchos. Dado que hay una relación uno-a-muchos para cada una de las 
entidades de datos, la relación entre ellos es muchos-a-muchos." El diagrama de entidad-re¬ 
lación sin normalizar se muestra en la figura El3.1, junto con las entradas del diccionario de 
datos para las tablas. 

Chip continúa: "Esta primera vista aún no está normalizada. Observa que BOARD 
CODE y SOFTWARE INVENTORY NUMBER son elementos que se repiten en la entidad 
HARDWARE. Tendré que crear varias entidades para cada uno de ellos". Un poco más 
tarde Chip revisa su trabajo con Anna. BOARD CODE se ha vuelto una entidad separada, 
enlazada por una entidad relacional, y SOFTWARE INVENTORY NUMBER se ha elimina¬ 
do y colocado en una entidad relacional. Consulte el diagrama de entidad-relación ilustrado 
en la figura El3.2. "Esto pone los datos en la primera forma normal", afirma Chip. "Asimis¬ 
mo, tampoco hay elementos que dependan sólo de una parte de la clave, así que los datos 
también están en la segunda forma normal. Sin embargo, hay elementos que no son parte de 
la entidad que se representa en el diagrama, y tendrán que ser eliminados. Por ejemplo, ob¬ 
serva DISPLAY ÑAME y PRINTER DESCRIPTION. Estos elementos no son parte de la 
computadora pero se conectan a ella. Deben tener su propia entidad. Esto hace más fácil el 
cambio de la escritura de, digamos, una impresora. En lugar de tener que cambiar la escritu¬ 
ra de la impresora en muchos de los registros de COMPUTER, sólo tendría que cambiarse 
una vez." 


Hardware Inventory Number + 

Brand Ñame + 

Model + 

Serial Number + 

Date Purchased + 

Purchase Cost + 

Replacement Cost + 

Memory Size + 

Hard Disk Capacity + I can 

Second Hard Disk Capacity + | have 

Floppy Drive + 

CD-ROM Drive + 

Zip Drive + 

NetWork + 

NetWork Connection Ñame + 

Display Ñame + 

Printer Description + 

Warranty + 

Campus Description + 

Room Location 



i 

Computer 



Hardware Inventory Number + 
Software Inventory Number + 


Hardware Inventory Number + 
Board Code 


has 


locates 



Software Inventory Number + 
Title + 

Operating System Ñame + 
Versión Number + 

Publisher + 

Software Category Description + 
Number of Media + 

Computer Brand + 

Computer Model + 

Memory Required + 

Display Ñame + 

Printer Description + 

Media Type + 

Site License + 

Number of Copies + 

Expert Last Ñame + 

Expert First Ñame + 

Office Phone 



Board Code + 
Board Ñame 



El diagrama de entidad-relación del sistema de cómputo en la primera forma normal. 



ASPECTOS ESENCIALES DEL DISEÑO 


























































Anna está de acuerdo, y comenta: "En realidad, ésta es una buena evaluación de la si¬ 
tuación. Facilitará mucho la implementación de las tablas de Microsoft Access". 

Chip continúa trabajando en el diagrama de entidad-relación. Unas horas más tarde 
exclama: "Creo que ya está. ¿Quieres darle un vistazo a la versión final?" Esta versión se 
muestra en la figura E13.3. Todas las entidades y relaciones se han descrito en el depósito. La 
figura E13.4 muestra la primera pantalla del depósito para la entidad COMPUTER. Ob¬ 
serve que el área Composition contiene los elementos finales para dar seguimiento a las 
computadoras y que las claves se indican mediante la notación [Pk] para la clave principal 
y [Alen] para una clave alterna, donde n representa cualquier número único. Las claves ex¬ 
ternas se encuentran en la parte más baja de la lista y se indican con la notación [Fk], La 
segunda pantalla contiene información sobre las relaciones que la entidad COMPUTER 
tiene con otras entidades, incluyendo la cardinal. Esta pantalla también contiene las ubica¬ 
ciones de la entidad. 

La relación PROVIDES SOLUTIONS FOR, que enlaza a SOFTWARE EXPERT y 
SOFTWARE, tiene una definición así como las entidades que están enlazadas en ambos ex¬ 
tremos de la relación. Se incluye la cardinal para cada extremo de la relación. 


r5) 


13 


Campus Code + 
Campus Description 


Campus Buliding 


has 

compuiers 
. withir 


are 

conneeted to 



Printer Code + 
Printer Description 


required by 


Brand Ñame + 
Model + 

Display Code + 
Printer Code + 
Warranty + 
Campus Code 


Hardware Inventory Number + J 
Board Code , " ^ 

-'''‘Computer^' 
Board Relattonaí 


is conneeted to Hardware Inventory Number - 
N. Software inventory Number 


has mínimum 
requirement 


Software Expert 


provides 

Solutions 

for 


Employee Number h 
E xpert Last Ñame + 
Expert First Ñame + 
Office Phone + 

Email Address + 
Department Code + 
Teach Course 


■—..-^iv- Sf 

can have 


'^^^Háidvrare^^> 

has 




- K 


«y 



Software Inventory Number t+ 
Tifie + 

are Operating System Ñame + 

Versión Number+ 

... .. . - p u p|¡sher + 

Software Category Code + 

described Display Code + 

¡,y Printer Code + 

Employee Number 


Software Category 


Display Code + 
Display Mame 


Software Category Code + 
Software Category Description 


Board Code + 
Board Ñame 


’t- v.- ■i r,-;' . i.:--; l yi ‘- 1 ." 

Diagrama de relación-entidad final para el sistema de cómputo. 
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Define Item 


Description | Locations ].Keys. j Foreign Keys 1 Triggersj Check Constramts f 


¡CompUer 


Label: 


Description: Contains Information about personal computéis used at Ceñiral Pacific 
Univeisity 


Corripoijtion: 

(Atlributes) 


(PK] Hardware Inventory Nurnber H- 
[AK1 ]BrandName + 

(AK2]Model + 

[AK3] Serial Numbert 
Date Purchased + 

Parchase Cost + 

ReplacernentCost + 

Memory Size + 

Hard Drive Capacity + 

Second Hard Drive Capacity + 
Floppy Diskette Drive + 

CD ROM Drive + 

Zip Drive Connected + 


Notes: 


Lo’ng Ñame; 


Nerf |.1;_Save i'Search i Jump' i- --Filé:|¡|]‘ History : ' 2 


¡ Cqpy j i !■; ■Search;£rjteria : i 


Exjt:.| bis Expahd 


> “ ‘‘ ... ■ 


— 


Pantalla de descripción áe entidaaes áe úuivihLirb.RS, la primera pantana áei depósrio. 


Anna repasa la última versión y exclama: "[Se ve muy bien! Fue buena decisión haber 
movido PRINTER y DISPLAY a sus propias entidades. Veo que CAMPUS BUILDING se 
ha movido a su propia entidad. Buena idea, puesto que el edificio no es parte de la compu¬ 
tadora. Asimismo, SOFTWARE EXPERT definitivamente no es parte de la entidad SOFTWA¬ 
RE. ¿Qué hay de SOFTWARE CATEGORY?" 

"Pasé SOFTWARE CATEGORY a su propia entidad para ahorrar espacio en los archi¬ 
vos maestros cuando se construyan", responde Chip. "En realidad es una tabla de códigos, y 
podemos almacenar un código pequeño en lugar de una descripción larga. ¿Por qué no revi¬ 
saste dos veces las diversas claves del diagrama? Cada entidad relacionada, en el extremo 
muchos, debe tener una clave externa que coincida con la clave principal de la entidad en el 
extremo uno." 

Anna examina el diagrama durante unos momentos y sugiere: "A mí me parece bien, 
¿pero por qué no ejecutas algunos de los informes de Visible Analyst para el diagrama de 
entidad-relación?" 

"[Esa es una excelente idea!", exclama Chip. El primer paso es ejecutar el verificador de 
sintaxis (Syntax Check} de Visible Analyst para el diagrama de entidad-relación final. Esta 
opción busca entidades y relaciones que no se hayan nombrado, y no produce ningún error 
cuando Chip la ejecuta. A continuación. Chip ejecuta la opción de análisis de normaliza- 
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ción (Normalization Analysis) que despliega una serie de mensajes de error. Estos mensajes 
informan a Chip que algunas de las relaciones tienen una cardinalidad uno-a-uno, que es acep¬ 
table. Los otros mensajes de advierten a Chip que SOFTWARE CATEGORY y CAMPUS 
BUILDING no tienen relaciones que los identifiquen. En consecuencia, las claves del registro 
no se han definido en el depósito. 

El siguiente análisis que Chip lleva a cabo es el informe de errores de análisis de claves 
(Key Analysis Errors}. Esta opción realiza un análisis de sintaxis y normalización, y reporta 
los problemas con las claves principales y las externas. En la figura E13.5 se ilustra el informe 
del análisis, que muestra que SOFTWARE CATEGORY no tiene ninguna clave principal y 
que PRINTER no tiene una relación que la identifique. El último informe de análisis que 
ejecuta Chip es el informe Model Balancing, el cual muestra algunos de los errores descubier¬ 
tos por los informes anteriores, pero, además, muestra todos los elementos que se encuentran 
en el área Composition de las entidades y que no son utilizados por algún proceso del dia¬ 
grama de flujo de datos. 

"Ahora que ya realizamos el análisis, observa cómo funciona esta característica", comenta 
Chip. "Voy a ejecutar la sincronización de claves [Key Synchronization]." 

"Pensé que ya habíamos acabado los informes", contesta Anna. 

"La sincronización de claves es más que un informe", responde Chip. "Definirá todas 
las claves externas del proyecto." 
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Error: 

Warning: 

Wammg: 

Warning: 

Error: 

Error: 

Error: 

Error: 

Error: 

Error: 

Error: 

Error: 

Error: 

Warning: 

J Warning: 

Eítot; 


Error: 

Error: 

Error: 

Error: 

Error: 

Error: 

Error: 




Attributive EnlitjJ 'Campus Buildmg' has no identifying Relationship attached. ¡i 
RelationsNp 'Room Located Withm Computer' is optional ¡n bolh directions. 
Relationship Vendor Provides Warranty Computer' is optional jn both directions. 
Relationship 'Printer Connected To Computer' is one to one mandatory. 

Oíd foreign key column 'Printer Code 1 m entity 'Computer' should be removed. 
Foreign key does not exist for Relationship 'Room Located Within Computer'. 
Foreign key does not exist for Relationship Vendor Provides Warranty 
Computer'. 

Foreign key does not exist for Relationship 'Printer Connected To Computer'. 
Attributive Entity ’Component Board’ has no umque primary key. 

Attributive Entity 'Computer Maintenance* has no unique primary key. 

Relationship 'Computer Contain Software' is not normalised. 

Foreign key does not exist for Relationship 'Software Category Described By 
Software'. 

Entity 'Maintenance' has no primary key defmed. 

Relationship 'Software Has Mínimum Requirement Monitor' is one to one 
mandatory. 

Relationship 'Computer Is Connected To Monitor' is one to one mandatory. 

Entity 'Monitor' has múltiple identifjiing relationships. This requires relationship 
'Software Has Mínimum Requirement Monitor’ to have a máximum cardinalíty 
greater than one. 

Entity 'Monitor' has múltiple identifying relationships. • This requires relationship 
'Computer Is Connected To Monitor 1 to have a máximum cardinalíty greater than 
one. 

Entity 'Peripheral Equiprnent' has no primary key defmed. 

Attributive Entity 'Printer' has no identifying Relationship attached. 

Entity 'Room' has no primary key defmed. 

Entity 'Software Category' has no primary key defined. 

Attributive Entity 'Software Category' has no identifying Relationship attached. 
Attributive Entity 'Software Category' has no unique primary key. 

Entity Vendor’ has no primary key defined. 
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"[Esto tengo que verlo!", exclama Anna, al tiempo que coloca una silla junto a Chip. 

"Primero tenemos que dibujar el diagrama de entidad-relación y definir las claves prin¬ 
cipales, lo cual ya hicimos", explica Chip. "Échale un vistazo a esta entrada del depósito." 
Chip abre el diagrama de entidad-relación y hace doble clic en la entidad COMPUTERS 
para abrir su entrada en el depósito. Se han definido la clave principal (la notación [pk] 
antes del elemento HARDWARE INVENTORY NUMBER en el área Composition) y va¬ 
rias claves alternas ([Akl], [Ak2] y [Ak3]). Chip hace clic en Repository y en Key 
Synchronization. Esto produce un informe para los analistas donde se indican los cambios 
que se realizaron a las tablas así como los errores que aún persisten. 

"Veamos nuevamente esta entrada del depósito", murmura Chip. "Mira, Key Synchro¬ 
nization ha agregado las claves externas necesarias." Estas claves se indican con la notación 
[FK] delante de las nuevas clave. La entidad COMPUTERS modificada se muestra en la fi¬ 
gura E13.6. 

Después de examinar el diagrama, así como las entradas del depósito y los informes de 
análisis, Anna y Chip están satisfechos porque las relaciones entre los datos se realizaron 


■'¡ Define ltém 


Description ■ j Locations ] Kejis j Foreign Keys j J riggersj Check Coristraints | 

Label / pT A pTnÑ , 

Entrvlype: . ínflE..' . O:/ zl '''., ' - Lili- í 


Entrvlype: liOTTil .r] 

Cornpos.ition: [pk] Hardware Inventor* Number B 
(Attributes). [AKIjBrandName + 

' [AK2] Model + 

[AK3] Serial Number + 

: Date Purchased + 

Purchase Cost + 

ReplacernentCost + 

B j——- Memor vSjze + 

Hard Orive Capacita + 

Second Hard Drive Capacity + 
Floppy Diskette Drive + 

• CD ROM Drive + 

Zip Drive Connected + 

Network+ 

NetWork Connection Ñame + 

_ • Monitor Code + 

• ; .Warranty + 

. Room Location 
[FKJPrmter Code 
[FKJCampus Code 
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con precisión. En seguida, deciden cómo diseñar los archivos o la base de datos a partir de 
los diagramas. 

Anna dice: "El sistema debe implementarse con Microsoft Access, porque una estructura 
de base de datos dará cabida fácilmente a las diversas relaciones". 

Primero se analiza la relación HARDWARE/SOFTWARE. Como hay una relación 
muchos-a-muchos entre estas dos entidades de datos, puede implementarse con tres tablas 
de base de datos: 


1. Una tabla HARDWARE MASTER. 

2. Una tabla SOFTWARE MASTER. 


3. Una tabla HARDWARE/SOFTWARE RELATIONSHIP que contendría los campos 
de clave para las tablas maestras HARDWARE y SOFTWARE para todo el software 
instalado en todas las máquinas. 


"Creo que ahora me toca trabajar en las relaciones", dice Anna al tiempo que toma una 
copia del diagrama de entidad-relación. "Modificaré las tablas de Microsoft Access a partir 
de las sesiones de creación de prototipos." 

Anna empieza por establecer las claves principales para cada una de las tablas. Cuando 
termina las tablas, procede a crear las relaciones entre ellas. En la figura E13.7 se muestra el 
diagrama de relaciones de Microsoft Access. Los rectángulos del diagrama representan las 
tablas de la base de datos y corresponden a los diversos tipos de entidades encontrados en 
el diagrama de entidad-relación. Observe que la cardinalidad se representa mediante" 1" y el 
símbolo de infinito. Los campos de las claves principales ocupan el primer campo de cada 
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Ejemplo que muestra el establecimiento de la integridad referencia! para la relación 
entre SOFTWARE CATEGORY CODES y SOFTWARE MASTER. 



Etlit IU:l«itiumhips 


láble/Query: Reiated Table/Query 

(Software Category jjSoftware Flaster 
i Software catego.ry _\J boftware Category 


Cancel 


JoinType. 


Créate New. 


Enfórce Réféféntiai .Infcegrítw —, 
W Cascade Update Reiated Fields 
V Cascade Delete Reiated Records 


Relationship lypo: . One I o Many 


rectángulo; también se muestran en negritas. Si las claves externas son visibles en el rectángu¬ 
lo de la tabla, se muestran conectadas al otro extremo de la línea de la relación. Las claves 
se arrastran de una tabla a otra para establecer una relación, y aparece un cuadro de diálogo 
para determinar las propiedades de la relación. Por ejemplo, la propiedad Enforce Referen- 
cial Integrity significa que usted no puede crear un registro en la tabla del extremo muchos 
sin crearlo primero en el extremo uno (que contiene la clave principal). La figura E13.8 
ilustra el establecimiento de la integridad referencial para la relación entre SOFTWARE 
CATEGORY CODE y SOFTWARE MASTER. Observe que la opción Cascade Update 
Reiated Fields aparece seleccionada. Si usted cambia un valor de SOFTWARE CATEGORY 
CODE, el mismo código se actualizará en SOFTWARE MASTER. No obstante, Casca¬ 
de Delete Reiated Records no está seleccionada. Usted no quiere que el sistema elimine 
un SOFTWARE CATEGORY CODE y que al mismo tiempo elimine todos los registros de 
SOFTWARE MASTER relacionados. 

"Me gustaría producir algo de documentación para el sistema", comenta Anna. "Seria 
útil cuando necesitáramos modificar tanto el diseño como los objetos y el código de Microsoft 
Access." En la característica Repository Reports hay diversas matrices que seria conveniente 
producir. La primera es Entities versus Data Stores Matrix. Esta matriz muestra las entida¬ 
des que se encuentran en todos los diagramas de entidad-relación y los almacenes de datos 
que contienen elementos similares. También es útil para transformar el diagrama de enti¬ 
dad-relación en diagrama de flujo de datos. 

La siguiente matriz que se produce es Composition Matrix. Esta proporciona una cua¬ 
drícula de referencias cruzadas de elementos y las entidades que los contienen. Esta matriz 
es útil para determinar qué entidades necesitan modificarse (o qué tablas de Microsoft Ac¬ 
cess) si cambia el tamaño del elemento o cualquier otra de sus características. Una última 
matriz que es útil para evaluar cambios a todo el sistema es la Diagram Location Matrix. En 
la figura E13.9 se encuentra un ejemplo de esta matriz, que muestra las entidades y los 
diagramas en los que se localizan. 
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■¡|p £ -4. Agregue la entidad MAINTENANCE al diagrama. A las computadoras se les hacen re¬ 
paraciones de mantenimiento, y la relación entre el MAINTENANCE y COMPUTER(s] 
es que una COMPUTER puede tener muchos registros de MAINTENANCE. 

’HÍ' í-5. Describa la entidad SOFTWARE CATEGORY en el depósito. Incluya los elementos 
que se encuentran en el diagrama de entidad-relación bajo SOFTWARE CATEGORY 
en el área Composition. 

'jfjp E-6. Describa la entidad MAINTENANCE en el depósito. Los elementos son los siguientes: 

a. MAINTENANCE ORDER NUMBER. 

b. HARDWARE INVENTOR Y NUMBER. 

c. MAINTENANCE DATE. 

d. TYPE OF MAINTENANCE. 

e. COST OF MAINTENANCE. 

£ MAINTENANCE COVERED BYWARRANTY. 

# E-7. Describa la entidad del VENDOR. Los elementos son los siguientes: 

a. VENDOR NUMBER. 

b. VENDOR ÑAME. 

c. STREET. 

d. CITY. 

e. STATE. 

£ ZIP CODE. 

g. TELEPHONE NUMBER. 

h. DATE LAST ORDER SENT. 

i. TOTAL AMOUNT PURCHASED FROM VENDOR. 

j. TOTAL NUMBER OF ORDERS SENTTO VENDOR. 

E-8. Produzca los siguientes informes usando Visible Analyst: 

a. Abra el diagrama de entidad-relación para el sistema de cómputo; a continuación 
aplique el verificador de sintaxis (Syntax Check) al diagrama (Diagram/Analyze/ 
Syntax Check]. 

b. Ejecute el informe de análisis de normalización (Normalization Analysis) para 
el diagrama de entidad-relación del sistema de cómputo (Diagram/Analyze/ 
Normalization}. 

c. El informe de análisis de claves (Key Analysis Report). 

d. El informe de sincronización de claves (Key Synchronization Report}. ¿Qué ha 
cambiado en el área Composition para cada una de las entidades? 

e. El informe de equilibrio del modelo (Model Balancing Report). 

£ La matriz Entities versus Data Stores Matrix. 

g. La matriz Composition Matrix. 

h. La matriz Diagram Location Matrix. 

E-9. Explique en un párrafo la relación entre una clave externa y una clave principal, y 
por qué es necesario tenerlas en entidades separadas cuando hay una relación entre 
las entidades. 









































TIPOS DE ¡NTERFAZ DE USUAREQ 

f!n csl.-i brmon so describen varios tipo;-: de intoríácv\s do usuario, entre ollas la* siguientes: 
interláces de Icnmuíjc natural, inlerláccs cié pre.uuma y respuesta, monús, hirmularioi-,/in- 
terláees i¡e leníiijíije de comando.,mterHicet: gráficas:cfeusunriü (CUJIs).V umi \iíriedad’de 
¡nurláces Web-panimso en Internet. ía ínterin/ de; usuario tiene.dos componentes:princi¬ 
pales el lenguaje de presentación, que es la parle computadora-humano de la transacción; 


OBJETIVOS DE APRENDIZAJE 


Una vez que haya dominado el material de este capítulo. podrá/./vss.í' 

: 1. Identificar una variedad de Interfaces de usuario y sus usos apropiados, 
i 2. Diseñar un diálogo eficaz para la comunicación humano-computadora. 

3. Entender la Importancia de siete tipos diferentes de retroallmentaclón del usuario de sistemas 
■ de información. 

4. Integrar las consideraciones de diseño especiales para los sitios Web de comercio electrónico. 

5. Formular considtas que permitan a los usuarios hacer búsquedas en la Web. 

G. Entender el concepto de minería de datos , : ” ,, 




Para U m.-wuría de loi usuarios, la Interna/ es ei sjsiema. .''ajrii-á \ m- e-;é bien ó pobrenu.-nle 
dt-eiMifá. e^ h; .¡"epii-jsenlación del sizlema y, por v.oLsjmiiíTIe, muestra la talijád i’:el jnaíis- 
M ¿fe Sistémás. - . '*'• í.-.'T. v'oró/ - 

Su mehí dí\Wz MT di-i-jñür interlace 1 -j¡t:e . KIKK é><..c UMKITÍOS y emiiivsa!- a eon'i-gülr 1:1 
iníprnuKlén une necesiten ¡lenlro V j;;era ¡le! sistema trálando de >\an/ar los arómenles 
‘ objetivos: ¿ ró/ró ;■ $ 

1. t km.f'-JO.ÍIK ¡Illr laJHKTf;!/ de u^/íarlo uní la ülrlM. 

2. 1 liuvr ilUiouU.- 1a niivrJa. de iníiurm. yy 

3. IVoporaonar a ÍMIarlns ¡;i n-lroal¡moL)t:kión jdi'.\iu:da. •./•i 

•f. Cn-ilr-rtM”colflilllrls üHH/ílllk's. ; . . ró ' , • . ". /•' V:*; ; ; 

5. Nlojorar L¡ pró¡fik-l¡vld". 1 U"dé iriíhalndorc A .de KIIHK ¡miento.' 

Con esrc A objetivos en mente, discutí remo?,. ton mayor detallo cómo so puelíe cumplir pon; 
cada unn ¡le olios. ■ :¿y, ' \ •/. f:•-ró '• 
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Interfaces de lenguaje natural. 
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> Mencione todos los vendedores de quienes se conocen sus cuotas este mes. 

Tom Orto 
Roz Berry 
Spin Etch 

> Compare el porcentaje de vegetales podridos en cada uno de nuestros almacenes. 

Fair Oaks 4% 

Tyson's 5% 

Metro Center 3% 




> Graflque la venta mensual de unidades de DVD de los últimos tres años. 

Presione cualquier tecla para continuar. í|[fej 


í/ííM 








y el lenguaje de acción, que caracteriza la parte humano-computadora. En conjunto, ambos 
conceptos cubren la forma y contenido del término interfaz de usuario. 


INTERFACES DE LENGUAJE NATURAL 

Las interfaces de lenguaje natural son quizás el sueño e ideal de usuarios inexpertos, debido 
a que permiten a usuarios interactuar con la computadora en su lenguaje cotidiano o natural. 
No se requieren habilidades especiales de usuarios, quienes interactúan con la computadora 
mediante lenguaje natural. 

La pantalla descrita en la figura 14.1 menciona tres preguntas de lenguaje natural de 
tres aplicaciones diferentes. Observe que la interacción con cada una parece muy fácil. Por 
ejemplo, la primera frase —"Mencione todos los vendedores de quienes se conocen sus cuo¬ 
tas este mes"— parece sencilla. 

Las sutilezas e irregularidades que residen en las ambigüedades del lenguaje natural 
producen un problema de programación sumamente exigente y complejo. Los intentos por 
interactuar con lenguaje natural para algunas aplicaciones en las cuales cualquier otro tipo 
de intefaz no es factible (por decir, en el caso de un usuario que está incapacitado) se está 
obteniendo con algo de éxito; sin embargo, estas interfaces normalmente son caras. Los pro¬ 
blemas de implementación y la demanda extraordinaria en los recursos de informática hasta 
ahora han mantenido las interfaces de lenguaje natural a un mínimo. Sin embargo, la de¬ 
manda existe y muchos programadores e investigadores están trabajando diligentemente en 
las interfaces de lenguaje natural. Es una área de crecimiento y, por lo tanto, merece super¬ 
visión continua. Algunos sitios Web, tal como Ask Jeeves (www.askjeeves.com), usan una 
interfaz natural para que los usuarios introduzcan su consulta de búsqueda. Cuando la con¬ 
sulta se introduce, Ask Jeeves responde con una lista de consultas que coincide con la pre¬ 
gunta que el usuario introdujo. 


INTERFACES DE PREGUNTA Y RESPUESTA 


En una interfaz de pregunta y respuesta, la computadora despliega en pantalla una pre¬ 
gunta para el usuario. Para interactuar, el usuario introduce una respuesta (mediante pulsa¬ 
ciones del teclado o un clic del ratón) y la computadora después actúa en esa información 
de entrada de acuerdo con su programa, normalmente pasando a la siguiente pregunta. 
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Un cuadro dé diálogo: tipo de 
interfaz ut p'réyüníd y respuesta, 


En la figura 14.2 se muestra un tipo de interfaz de pregunta y respuesta denominado 
cuadro de diálogo. Un cuadro de diálogo actúa como una interfaz de pregunta y respuesta 
dentro de otra aplicación, en este caso un diagrama PERT para un proyecto de análisis de 
sistemas para Bakerloo Brothers. Observe que el rectángulo redondeado para "Sí" está resal¬ 
tado, lo que indica que es la respuesta más común para esta situación. La interfaz principal 
para esta aplicación no necesariamente debe ser de pregunta y respuesta. Más bien, al incor¬ 
porar un cuadro de diálogo, el programador ha incluido una interfaz de fácil uso dentro de 
una más complicada. 

Los asistentes usados para instalar software son un ejemplo común de una interfaz de 
pregunta y respuesta. El usuario responde a las preguntas acerca del proceso de instala¬ 
ción, tal como dónde instalar el software o características. Otro ejemplo común es el uso 
del Asistente de Office usado en los productos de Microsoft. Cuando el usuario necesita 
ayuda, el Asistente de Office hace preguntas y reacciona a las respuestas con preguntas 
adicionales diseñadas para limitar el alcance del problema. Los usuarios que no están fami¬ 
liarizados con aplicaciones particulares o no están informados sobre un tema podrían en¬ 
contrar interfaces de pregunta y respuesta más cómodas, ganando rápidamente confianza a 
través de su éxito. 


MENÚS 

Una interfaz de menús adquiere apropiadamente su nombre de la lista de platillos que se 
pueden seleccionar en un restaurante. De forma similar, una interfaz de menú proporciona 
al usuario una lista en pantalla de las selecciones disponibles. 

En respuesta al menú, un usuario está limitado a las opciones desplegadas. El usuario 
no necesita conocer el sistema pero tiene que saber qué tarea se debe realizar. Por ejemplo, 
con un menú típico de procesamiento de texto, los usuarios pueden escoger opciones para 
editar, copiar o imprimir. Sin embargo, para utilizar el mejor menú los usuarios deben saber 
qué tarea desean desempeñar. 

Los menús no dependen del hardware. Las variaciones abundan. Los menús se estable¬ 
cen para usar el teclado, lápiz óptico o el ratón. Las selecciones se pueden identificar con un 
número, carta o palabra clave. La consistencia es importante en el diseño de una interfaz de 
menú. 
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Los menús también se pueden ocultar hasta que el usuario quiera usarlos. La figura 
14.3 muestra cómo se usa un menú desplegable al construir un diagrama PERT para un 
proyecto de análisis de sistemas a ser completado para Bakerloo Brothers. El usuario coloca 
el puntero en Fechas y lo despliega. Después el usuario coloca el puntero en Calendario, 
que selecciona la opción para desplegar el proyecto en un calendario mensual convencional. 

Los menús se pueden anidar dentro de otro para llevar a un usuario a las opciones de 
un programa. Los menús anidados permiten a la pantalla aparecer menos desordenada, la 
cual es consistente con el adecuado diseño. También permiten a usuarios evitar ver opciones 
de menú en las que no están interesados. Los menús anidados también pueden mover rápi¬ 
damente a los usuarios a través del programa. 

Los menús de GUI se usan para controlar el software de PC y tienen los siguientes li¬ 
ncamientos: 


§¡B| ‘ 


1. Siempre se despliega la barra de menú principal. 

2. El menú principal usa palabras simples para los artículos del menú. Las opciones de 
menú principales siempre despliegan menús desplegables secundarios. 

3. El menú principal debe tener opciones secundarias agrupadas en grupos similares de 
características. 

4. Los menús desplegables que se presentan cuando se hace clic en un artículo de menú 
principal con frecuencia consisten en más de una palabra. 

5. Estas opciones secundarias desempeñan acciones o despliegan artículos de menú adi¬ 
cionales. 

6. Los artículos de menú en gris no están disponibles para la actividad actual. 

Un menú de objeto, también llamado menú desplegable independiente,'se despliega 
cuando el usuario hace clic en un objeto de la GUI con el botón derecho del ratón. Estos 
menús contienen artículos específico para la actividad actual y la mayoría es funciones du¬ 
plicadas de artículos de menú principales. 

Los usuarios experimentados se podrían fastidiar por los menús anidados. Preferirían 
usar una entrada de comandos de línea simple para acelerar las cosas. Otros usuarios po¬ 
drían usar los métodos abreviados o las combinaciones de teclas como Alt + I, P, C, la cual 
inserta una la figura de clip art en un documento de Microsoft Office. 
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PREFERI R IA HACER LO YO MISMO 


"Puedo pedir a Mickey que baje de la Web o de nuestro servidor a mi 
PC los datos que necesito", le dice a usted DeWitt Miwaye, un alto ejecu¬ 
tivo de Yumtime Foods (un mayorista de alimentos del Medio Oeste). 
"Obtener los datos no es el problema. Lo que no quiero son muchos re¬ 
portes. Prefiero analizar los datos yo mismo." 

Miwaye le dice a usted que, como ejecutivo, él no usa su PC con la 
frecuencia que quisiera, tal vez sólo tres veces por mes, pero sabe bien lo. 
que le gustaría hacer con elía. 

"Me gustaría hacer algunas comparaciones por mí mismo. Podría 
comparar el índice de rotación de empleados de nuestros 12 almacenes. 


También me gustaría ver la eficacia con que se utiliza cada uno de nues¬ 
tros almacenes. A menudo quisiera poder construir una gráfica de las 
comparaciones o ver un análisis de ellas en relación con el tiempo." 

En tres párrafos, compare tres tipos distintos de interfaz que podría 
usar Miwaye. A continuación recomiéndele una interfaz qué tome en 
cuenta la poca frecuencia con que utiliza la PC, la forma en que disfru¬ 
ta trabajar con datos puros y su deseo de desplegar datos en diversas 
formas; 


INTERFACES DE FORMULARIO (FORMULARIOS DE ENTRADA/SALIDA) 

Las interfaces de formulario consisten de formularios en pantalla o formularios que se ba¬ 
san en la Web que despliegan campos que contienen datos o parámetros que necesitan ser 
comunicados al usuario. El formulario a menudo es un facsímil de un formulario impreso 
que ya es familiar para el usuario. Esta técnica de interfaz también se conoce como método 
basado en el formulario y en formularios de entrada/salida. 

La figura 14.4 muestra una interfaz de formulario. Un menú desplegable para el Núm. 
de la parte introduce automáticamente una Descripción y un Precio de la unidad para el 
artículo. Cuando el usuario pasa al campo Cantidad e introduce el número de artículos a 
ser comprados, el software calcula automáticamente el Precio extendido multiplicando la 
Cantidad y el Precio de la unidad. 

Los formularios para las pantallas de despliegue se configuran para mostrar qué infor¬ 
mación debe introducirse y dónde. Los campos en blanco requieren información que se 
puede resaltar con caracteres inversos o intermitentes. Por ejemplo, el usuario mueve el 
cursor de un campo a otro mediante la pulsación de una tecla de flecha. Esta disposición 
permite moverse un campo hacia atrás o un campo hacia adelante oprimiendo la tecla de 
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flecha correspondiente. Los formularios que se basan en la Web ofrecen la oportunidad de 
incluir hipervínculos para ejemplos de formularios completados correctamente o para ayu¬ 
da extensa y ejemplos. 

Los formularios de entrada para las pantallas se pueden simplificar proporcionando va¬ 
lores predeterminados para los campos y permitiendo que los usuarios modifiquen la infor¬ 
mación predeterminada si es necesario. Por ejemplo, un sistema de administración de base 
de datos diseñado para mostrar un formulario para introducir cheques prodría proporcionar 
el siguiente número secuencial de cheque como valor predeterminado cuando se exhibe un 
nuevo formulario de cheque. Si faltan cheques, el usuario cambia el número de cheque para 
reflejar el cheque real a ser introducido. 

La entrada para los campos de pantallas de despliegue se puede restringir de manera 
que, por ejemplo, los usuarios puedan introducir únicamente números en un campo que so¬ 
licita el número del seguro social o pueden introducir únicamente letras donde se pide el 
nombre de una persona. Si los números son la entrada donde sólo se permiten letras, la 
computadora podría alertar al usuario que el campo se completó incorrectamente. 

La ventaja principal de la interfaz de formulario de entrada/salida es que la versión im¬ 
presa del formulario proporciona documentación excelente. Muestra etiquetas para cada 
campo así como también contexto para las entradas. Los documentos que se basan en la 
Web se pueden enviar directamente al sistema de facturación si se involucra una transacción 
o pueden ir directamente a la base de datos del cliente si se está enviando una encuesta. Los 
formularios que se basan en la Web hacen al usuario responsable por la calidad de los datos 
y hacen disponible el formulario para completarlo y enviralo en 24 horas, 7 días a la sema¬ 
na, desde cualquier parte del mundo. 

Hay algunas desventajas con los formularios de entrada/salida. La desventaja principal 
es que los usuarios experimentados se podrían impacientar con estos formularios y querrían 
formas más eficaces para introducir datos. 

INTERFACES DE LENGUAJE DE COMANDOS 

Una interfaz de lenguaje de comandos permite al usuario controlar la aplicación con una se¬ 
rie de pulsaciones del teclado, comandos, frases o alguna secuencia de estos tres métodos. Es 
una interfaz popular que es más refinada que las discutidas anteriormente. 

En la figura 14.5 se muestran dos ejemplos de la aplicación de lenguaje de comandos. 
El primero muestra a un usuario que pide usar un archivo que contiene datos de todos los 
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NO HAGAN QUE ME ATRASE 


"Las he visto todas", dice Carne Moore. "Yo estaba aquí cuando ellos 
compraron su primera computadora. Creo que he hecho una especie de 
carrera de esto", afirma alegremente, señalando hacia la enorme pila 
de formularios de solicitud de reembolso de gastos médicos que ha estado 
ingresando en el sistema de cómputo.: En su calidad de analista de sis¬ 
temas, usted entrevista a Carrie, quien se desempeña como capturista 
de datos de HealthPlus (una enorme compañía de seguros médicos), en 
relación con los cambios que se realizarán al sistema de cómputo. 

"En comparación con las demás, soy bastante rápida", dice Carrie 
señalando con la cabeza hacia las otras seis capturistas que se encuen¬ 
tran en la misma sala. "Lo sé porque a menudo realizamos breves com¬ 
petencias para ver quién es la más rápida y con menos errores. ¿Ve esa 
gráfica sobre la pared? Ahí se muestra la cantidad de formularios que 
introducimos al sistema y con qué rapidez. Las estrellas doradas indican 
quién es la mejor cada semana," 

"En realidad no me afecta si cambian las computadoras. Como le di¬ 
je, las he visto todas." Carrie reanuda su trabajo mientras continúa la 


entrevista. "No obstante, independientemente de lo que hagan, no ha¬ 
gan que me atrase. Una de las cosas de las cuales estoy más orgullosa 
es que aún puedo vencer a las demás capturistas. Sin embargo, ellas 
también son buenas", agrega Carrie. 

Con base en esta entrevista parcial con Carrie Moore, ¿qué tipo de in¬ 
terfaz de usuario diseñará para ella y las demás capturistas? Suponga 
que el nuevo sistema también requerirá la captura de grandes cantida¬ 
des de datos procedentes de diversos tipos de formularios de reembolso 
de gastos médicos enviados por los solicitantes. 

Compare y contraste interfaces como el lenguaje natural, preguntas 
y respuestas, menús, formularios de entrada/salida y documentos basa¬ 
dos en la Web. Después elija y defienda una. opción. ¿Cuáles cualidades 
de Carrie y las demás operadoras —y de los datos que tendrán que cap¬ 
turar— influyeron en su elección? Haga una lista de estas cualidades. 
¿Es factible más de una opción? ¿Por qué sí o por qué no? Dé su respues¬ 
ta en un párrafo. 


vendedores y pide a la computadora desplegar todos los apellidos, seguidos de los nombres, 
para todos los vendedores cuyas ventas actuales [VENTAS ACTUALES) son mayores que 
sus cuotas. En el segundo ejemplo, un usuario pide usar un archivo llamado TENDERO y 
dirige a la computadora para calcular las mermas (MERMAS] restando el producto vendido 
del producto comprado. Una vez hehco esto, el usuario pide regresar a la parte superior del 
archivo e imprimirlo (LISTAR). 

El lenguaje de comandos no tiene un significado inherente para el usuario y este hecho 
lo hace bastante diferente a las otras interfaces discutidas hasta ahora. Los lenguajes de 
comandos manipulan a la computadora como una herramienta para permitir al usuario 
controlar el diálogo. El lenguaje de comandos ofrece al usuario mayor flexibilidad y control. 
Cuando el usuario da una instrucción a la computadora mediante lenguaje de comandos, 
se ejecuta de inmediato por el sistema. Después el usuario podría proceder para dar otra 
instrucción. 

Los lenguajes de comandos requieren memorizar las reglas de sintaxis, esto general¬ 
mente es un obstáculo para los usuarios inexpertos. Los usuarios experimentados tienden a 
preferir los lenguajes de comandos, posiblemente porque les permite trabajar más rápido. 


INTERFACES GRAFICAS DE USUARIO 

Las interfaces gráficas de usuario (GUIs) permiten la manipulación directa de la represen¬ 
tación gráfica en pantalla, la cual se puede realizar con la entrada del teclado, una palanca 
de juego o el ratón. La manipulación directa requiere mayor sofisticación del sistema que 
las interfaces vistas anteriormente. 

La clave para las GUIs es la retro alimentación constante que proporcionan. La retroali- 
mentación continua en el objeto manipulado significa que se pueden hacer rápidamente los 
cambios o incluso cancelar operaciones sin incurrir en mensajes de error. El concepto de re¬ 
tro alimentación para los usuarios se discute más a fondo en una sección más adelante. 

La creación de GUIs representa un reto, debido a que se debe inventar un modelo 
apropiado de realidad o un modelo conceptual aceptable de la representación. El diseño de 
GUIs para uso en intranets, extranets y, aún más urgente, en Web, requiere una planeación 
más cuidadosa (véase el capítulo 12 en el diseño de sitio Web). En general, los usuarios de si¬ 
tios Web son desconocidos para el diseñador, de modo que el diseño debe ser bien definido. 
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instalaciones de renta de automóvil. También se pueden usar para explicar los dioramas en 
los museos y para localizar los sitios de campamento en los parques estatales. Las pantallas 
sensibles al tacto no requieren experiencia especial de los usuarios y son autónomas, no ne¬ 
cesitan ningún dispositivo de entrada especial que se podría romper o robar. 

El reconocimiento de voz ha sido, durante mucho tiempo, el sueño de científicos y es¬ 
critores de ciencia ficción. Es intuitivamente atractivo, debido a que se aproxima a la comu¬ 
nicación humana. Con el reconocimiento de voz, el usuario habla con la computadora y el 
sistema puede reconocer los signos vocales de un individuo, convertirlos y almacenar la en¬ 
trada. Los sistemas de inventario de reconocimiento de voz ya están en funcionamiento. 

Una ventaja de sistemas de reconocimiento de voz es que pueden acelerar enormemen¬ 
te la entrada de datos y dejan libres las manos del usuario para otras tareas. La entrada de 
voz todavía agrega otra dimensión a la PC. Ahora es posible agregar equipo y software que 
permitan a un usuario de PC hablar los comandos tales como "abrir archivo" o "guardar 
archivo" para evitar usar el teclado o ratón. Las ventajas obvias de esta tecnología son in¬ 
crementar la exactitud y la velocidad de lo que ofrecen los movimientos del ratón con¬ 
vencional, así como también la anulación de lesiones de tensión repetitivas tal como el 
síndrome del túnel carpiano que puede debilitar la muñeca y mano. 

Los dos desarrollos principales en el reconocimiento de voz son (1] sistemas de lengua¬ 
je continuos, los cuales permiten entrada de texto regular en los procesadores de texto y (2} 
la independencia del orador para que cualquier número de personas pueda introducir co¬ 
mandos o palabras en una estación de trabajo dada. 

Los productos Dragón NaturallySpeaking de ScanSoft incluyen sistemas de dictado, 
sistemas de comandos y sistemas de texto a voz. Dragón NaturallySpeaking fue el primer 
producto de reconocimiento para la PC con un vocabulario amplio de voz continua. Ahora 
está disponible en una versión de red para que el reconocimiento de voz se pueda compar¬ 
tir en la organización. El vocabulario no es solamente una lista de ortografía, sino que incluye 
información de uso de lenguaje independiente del orador y ruidos acústicos, lo que repre¬ 
senta un reconocimiento más exacto. 

Un usuario puede dar una instrucción a la computadora y se ejecutará. En el ejemplo 
mostrado en la figura 14.6, el usuario corrige una palabra desplegando un menú de palabras 
alternativas que suenan igual. 
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Al evaluar las interfaces que ha escogido, debe tener en cuenta algunas normas: 

1. El periodo de entrenamiento necesario para los usuarios debe ser aceptablemente 
corto. 

2. Los usuarios antes de su entrenamiento deben poder introducir comandos sin pensar 
en ellos o sin consultar el menú de ayuda o el manual del usuario. Mantener consisten¬ 
tes las interfaces en las aplicaciones ayuda mucho a este respecto. 

3. La interfaz debe ser perfecta para que haya pocos errores y los que ocurran no sea por 
un mal diseño. 

4. El tiempo que los usuarios y el sistema necesitan para recuperarse de los errores debe 
ser corto. 

5. Los usuarios poco frecuentes deben poder aprender a usar el sistema en poco tiempo. 

Actualmente se dispone de muchas interfaces, por lo que es importante tomar en cuenta 
que una interfaz eficaz tiene mucho que ver para llamar la atención de los usuarios. En la si¬ 
guiente sección, veremos la importancia de proporcionar retroalimentación a los usuarios 
para apoyar su trabajo con el sistema. 


LINEAilENTÓS PARA ÉL DISEÑÓ DÉ DIÁLOGOS 

El diálogo es la comunicación entre la computadora y una persona. Un diálogo bien diseña¬ 
do facilita a las personas usar una computadora y tener menos frustración con el sistema de 
cómputo. Hay varios puntos clave para diseñar un buen diálogo. Algunos de ellos se men¬ 
cionaron en el capítulo 12. Estos incluyen lo siguiente: 

1. Comunicación significativa, para que la computadora entienda qué están introducien¬ 
do las personas y para que las personas entiendan qué se les está presentando o qué es¬ 
tán pidiendo a la computadora. 

2. Acción mínima del usuario. 

3. Funcionamiento normal y consistente. 


COMUNICACIÓN SIGNIFICATIVA 


El sistema debe presentar la información con claridad al usuario. Esto significa tener un 
título apropiado para cada pantalla, minimizar el uso de abreviaciones y proporcionar re¬ 
troalimentación útil. Los programas de consulta deben desplegar los significados del código 
así como también los datos en un formato editado, tal como desplegar las diagonales entre 
el mes, día y año en un campo de fecha o comas y puntos decimales en un campo de can¬ 
tidad. Las instrucciones de usuario deben incluir detalles tales como las teclas de función 
disponibles. En una interfaz gráfica, el cursor podría cambiar de forma dependiendo del 
trabajo que se esté desempeñando. 

Los usuarios con menos habilidad requieren más comunicación. Los sitios Web deben 
desplegar más texto e instrucciones para guiar al usuario a través del sitio. Los sitios de in¬ 
tranet podrían tener menos diálogo, debido a que hay una medida de control sobre qué tan 
bien están capacitados los usuarios. Los gráficos de Internet deben tener descripciones de 
texto desplegables cuando las imágenes se usan como hipervínculo, debido a que podría ha¬ 
ber incertidumbre en la interpretación de su significado, sobre todo si el sitio se usa interna¬ 
cionalmente. Otra forma de proporcionar instrucciones para los usuarios en las pantallas 
GUI es mediante una línea de estatus. 

Se deben proporcionar pantallas de ayuda de fácil uso. Muchas pantallas de ayuda de 
PC tienen temas adicionales que se podrían seleccionar directamente usando el texto resal¬ 
tado desplegado en la primera pantalla de ayuda. Estos hipervínculos normalmente están en 
un color diferente, el cual los hace resaltar en contraste con el resto del texto de ayuda. 
Muchas de las GUIs más nuevas también incorporan sugerencias, desplegando un mensaje 
de ayuda pequeño que identifica la función de un botón de comando cuando el cursor se 
coloca sobre él. El otro lado de la comunicación es que la computadora debe entender lo 
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que el usuario ha introducido. Por lo tanto, todos los datos introducidos en la pantalla se de¬ 
ben editar para verificar su validez. 


ACCIÓN MÍNIMA DE USUARIO 

La codificación con frecuencia es la parte más lenta de un sistema de cómputo y un buen 
diálogo minimizará el número de pulsaciones del teclado requeridas. Puede lograr esta me¬ 
ta de varias formas: 

1. Codificar los códigos en lugar de las palabras completas en las pantallas de entrada. Los 
códigos también se codifican al usar una interfaz de lenguaje de comandos. Un ejemplo 
es introducir una abreviación de dos letras en lugar del nombre del estado en una direc¬ 
ción. En una pantalla de GUI, los códigos se podrían introducir seleccionándolos de un 
lista desplegable de códigos disponibles. 

2. Introducir únicamente datos que aún no están almacenados en los archivos. Por ejem¬ 
plo, al cambiar o eliminar los registros de artículo sólo se debe introducir el número del 
artículo. La computadora responde al desplegar información descriptiva que se almace¬ 
na actualmente en el archivo del artículo. 

3. Proporcionar caracteres de edición (por ejemplo, diagonales como separadores de cam¬ 
po de fecha). No es necesario que los usuarios introduzcan caracteres de formateo tales 
como ceros a la izquierda, comas o un punto decimal al introducir una cantidad en dó¬ 
lares; ni tampoco necesitan introducir diagonales o guiones al introducir una fecha. 

4. Usar valores predeterminados para los campos en las pantallas de entrada. Los valores 
predeterminados se usan cuando un usuario introduce el mismo valor en un campo de 
la pantalla para la mayoría de los registros a ser procesados. El valor se despliega y el 
usuario podría presionar la tecla Enter para aceptar el valor predeterminado o sobrees¬ 
cribirlo con otro nuevo. 

Las GUIs podrían contener casillas de verificación y botones de opción que se 
seleccionan cuando se abre un cuadro de diálogo. Proporcione menús sensibles al con¬ 
texto que aparecen cuando se hace clic en un objeto con el botón derecho del ratón. 
Estos menús contienen opciones específicas para el objeto bajo el ratón. 
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5. Diseñar un programa para consultar registros de modo que el usuario sólo necesite in¬ 
troducir los primeros caracteres de un nombre o descripción del artículo. El programa 
despliega una lista de todos los nombres de coincidencia, y cuando el usuario escoge 
uno, se despliega el registro correspondiente. 

6. Proporcionar pulsaciones del teclado para seleccionar opciones del menú desplegable. 
Con frecuencia, estas opciones se seleccionan usando un ratón, seguido por algún te¬ 
cleo. Los usuarios deben mover sus manos del teclado al ratón y viceversa. Conforme 
los usuarios se familiaricen con el sistema, las pulsaciones del teclado proporcionan un 
método más rápido para manipular los menús desplegables, debido a que ambas manos 
permanecen en el teclado. 

En una PC, normalmente las pulsaciones del teclado involucran presionar una 
tecla de función o la tecla Alt seguida por una letra. La figura 14.7 es un ejemplo de 
menús desplegables anidados con teclas de método abreviado de Microsoft Visio Profes- 
sional. Observe que el usuario, quien está creando una gráfica de estructura, puede en¬ 
trar en una serie de menús más específicos. 

Cualquier combinación de estos seis enfoques puede ayudar al analista a disminuir el nú¬ 
mero de pulsaciones requerido por el usuario, por esa razón aumenta la velocidad de entra¬ 
da de datos y minimiza los errores. 

FUNCIONAMIENTO NORMAL Y CONSISTENCIA 

El sistema debe ser consistente en su juego de pantallas y en los mecanismos para controlar 
el funcionamiento de las pantallas en las diferentes aplicaciones. La consistencia hace más 
fácil para los usuarios aprender a usar nuevas partes del sistema una vez que están familia¬ 
rizados con un componente. Puede lograr la consistencia mediante lo siguiente: 

1. Localizar títulos, fecha, tiempo y mensajes de retroalimentación en los mismos lugares 
en todas las pantallas. 

2. Salir de cada programa mediante la misma clave u opción de menú. Sería un diseño po¬ 
bre usar la tecla de función 4 (F4) para salir del programa AGREGAR CLIENTE y la 
tecla de función 6 (F6) para salir del programa CAMBIAR CLIENTE. 
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Ejemplo de menús desplegables 
anidados con teclas de método 
abreviado de Microsoft Visio 
Professíonal. 
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3. Cancelar una transacción de forma consistente, normalmente usando una tecla de fun¬ 
ción [generalmente F12) en una computadora central y la tecla Esc en una PC. 

4. Obtener ayuda de forma estandarizada. La tecla estándar para la ayuda es la tecla de 
función 1 (Fl) y la mayoría de los desarrolladores de software está adoptando esta con¬ 
vención. 

5. Estandarizar los colores usados para todas las pantallas. Los mensajes de error normal¬ 
mente se despliegan en rojo. Recuerde mantener el mismo color de fondo de pantalla 
para todas las aplicaciones. 

6. Estandarizar el uso de iconos para funciones similares al usar una interfaz gráfica de 
usuario. Por ejemplo, un pedazo pequeño de papel con una esquina superior torcida con 
frecuencia representa un documento. 

7. Usar terminología consistente en una pantalla de despliegue o sitio Web. 

8. Proporcionar una forma consistente para navegar entre los diálogos. Por ejemplo, en¬ 
cuentre una forma consistente para agregar registros o para trabajar con un sitio Web, 
tal como usar los mismos botones para Atrás y Adelante. 

9. Usar alineación, tamaño y color de fuente consistente en una página Web. 

En la figura 14.8 se muestra un cuadro de diálogo con fichas que es un ejemplo de di¬ 
seño adecuado de GUI. Actualmente, el usuario está escogiendo opciones de impresión 
de HP LaserJet y está en la ficha Paper, pero también tiene la opción de otras seis fichas, 
incluyendo Fonts y Graphics. Esta pantalla muestra las opciones que un usuario puede 
seleccionar haciendo clic en las flechas izquierda o derecha en la barra de desplazamiento 
horizontal que corre a lo largo del fondo de la ventana de Paper size (tamaño de página), 
"Com-10 Env", "Monarch E", "DL Env", "C5 Env", etc. El área oscura indica que el usua¬ 
rio ha escogido imprimir un sobre de C5. Observe que el diseñador de esta interfaz ha 
usado botones de opción para Layout y Orientation. El usuario ha hecho clic en la opción 
Vertical para la orientación. También se usa un menú desplegable para seleccionar el Paper 
source (fuente del papel). En este caso, el usuario ha escogido la Bandeja de AutoSelect. 
El diseñador también ha usado botones de comando hasta la parte inferior de la pantalla 
que permite a usuarios presionar OK, Cancel o Apply con respecto a las opciones que han 
elegido. 
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Esto cuadro do diálogo tiene 
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"Sí, nos vendieron un paquete. El que está aquí. No me malinterpre- 
tes, trabaja bien, solamente que no sabemos cuándo." 

Usted está conversando con Owen Itt, quien le habla acerca de la re¬ 
ciente compra de nuevo software de la Unidad de Ventas, para sus PCs, 
que permitirá a cada uno de sus 16 empleados de ventas introducir datos 
sobre ventas, les ofrecerá datos para comparar la salida y proyectará las 
ventas futuras con base en los registros de ventas pasadas. 

"Sin embargo, hemos tenido algunas experiencias peculiares con este 
programa", continúa Owen. "Parece lento o algo así. Por ejemplo, nunca 
estamos seguros cuándo termina. Escribo un comando para obtener un 
archivo y no pasa nada. Casi medio minuto después, si tengo suerte, 
aparecerá la pantalla que busco, pero nunca estoy seguro. Si le Indico 
que guarde datos de ventas, sólo escucho un zumbido. Si funciona, en 


seguida me regresa a donde estaba antes. Si no guarda los datos, de to¬ 
das maneras me regresa al sitio donde estaba antes. Es confuso, y nun¬ 
ca sé qué hacer. No hay ninguna pista en la pantalla que me indique qué 
hacer a continuación. ¿Ve el manual que acompaña al software? Tiene 
muchas hojas con esquinas dobladas porque continuamente tenemos 
que marcarlo para averiguar qué hacer a continuación." 

Con base en lo que escuchó en la entrevista, tome esta oportunidad 
para complementar el programa y diseñe algunas guías de retroallmenta- 
ción en pantalla para Owen y su equipo de ventas. Esta retroalimentación 
debe responder todas las preocupaciones de Owen. Siga los lineamientos 
para ofrecer retroalimentación a los usuarios y aquellos que se refieren 
al buen diseño de pantallas. Dibuje un prototipo de las pantallas que 
considere necesarias para resolver los problemas que mencionó Owen. 


RETROALIMENTACIÓN PARA LOS USUARIOS 

Como se discutió en el capítulo 2, todos los sistemas necesitan retroalimentación para su¬ 
pervisar y cambiar su funcionamiento. Normalmente la retroalimentación compara el fun¬ 
cionamiento actual con las metas predeterminadas y devuelve información que describe la 
diferencia entre el desempeño actual y el pretendido. 

Debido a que los humanos en sí son sistemas complejos, requieren retroalimentación 
de otros para conocer las necesidades psicológicas. La retroalimentación también aumenta 
la confianza humana. Cuánta retroalimentación se requiere, depende de las características 
de cada individuo. 

Cuando los usuarios interactúan con las máquinas, aún necesitan retroalimentación 
acerca de cómo ha progresado su trabajo. Como diseñadores de interfaces de usuario, los 
analistas de sistemas necesitan estar conscientes de la necesidad humana por la retroalimen¬ 
tación y construirla en el sistema. Además de los mensajes de texto, con frecuencia se puden 
usar iconos. Por ejemplo, al desplegar un reloj de arena mientras el sistema está procesando 
algo, alienta a que el usuario espere por algún tiempo en lugar de oprimir repetidamente las 
teclas para intentar obtener una respuesta. 

Como se muestra en la figura 14.9, la retroalimentación al usuario es necesaria en siete 
situaciones diferentes. La retroalimentación que es inoportuna o demasiado abundante no 
es útil, debido a que sólo podemos procesar una cantidad limitada de información. En las 
siguientes subsecciones se explica cada una de las siete situaciones en que la retroalimenta¬ 
ción es apropiada. Los sitios Web deben desplegar un mensaje de estado o alguna otra for¬ 
ma de notificar al usuario que el sitio está respondiendo y esa entrada es correcta o necesi¬ 
ta información más detallada. 
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Lá retroalimentación se usa 
de muchas formas. 


La retroalimentación es necesaria para decirle al usuario que: 


• La computadora ha aceptado la entrada;,;/;; 

@ La entrada.es correcta-.. " ’ ' 

0 La entrada es Incorrecta. r 

• Habrá un retraso en el procesamiento, 
o-La petición seí háíco.mpletadQí jj 5 ;: LTlÍT LjPi: :j; S Jí 

La computadora no está disponible para completar la petición. 


Hay retroalimentación más detallada (y cómo obtenerla). 
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TIPOS DE RETROALIMENTACIÓN 


Reconociendo la aceptación de la entrada La primera situación en que los usuarios ne¬ 
cesitan la retroalimentación es saber que la computadora ha aceptado la entrada. Por ejem¬ 
plo, cuando un usuario introduce un nombre en una línea, la computadora proporciona 
retroalimentación al usuario avanzando el cursor un carácter a la vez cuando las letras se in¬ 
troducen correctamente. 

Reconociendo que la entrada es correcta Los usuarios necesitan retroalimentación que 
les diga que la entrada es correcta. Por ejemplo, un usuario introduce un comando y la 
retroalimentación declara "LISTO" como progresos del programa a un nuevo punto. Un 
ejemplo pobre de retroalimentación que le dice al usuario que la entrada es correcta es el 
mensaje "ACEPTAR ENTRADA", debido a que ese mensaje toma espacio extra, es críptico, 
y no hace nada para alentar la entrada de más datos. 

Notificando que la entrada es incorrecta La retroalimentación es necesaria para advertir a 
los usuarios que la entrada no es correcta. Cuando los datos son incorrectos, una forma de 
notificar a los usuarios es generar una ventana que describa brevemente el problema con la 
entrada y que le diga al usuario cómo corregirlo, como se muestra en la figura 14.10. 

Observe que el mensaje acerca de un error en la introducción del periodo de suscrip¬ 
ción es correcto y conciso pero no críptico, de modo que incluso los usuarios inexpertos 
podrán entenderlo. El periodo de suscripción introducido es incorrecto, pero la retroalimen¬ 
tación dada no hace hincapié en el error del usuario. Más bien, ofrece opciones (13, 26 o 52 
semanas] para que el error se pueda corregir fácilmente. En una pantalla de GUI, con fre¬ 
cuencia la retroalimentación aparece en forma de un cuadro de mensaje con un botón de 
ACEPTAR. Normalmente los mensajes Web se envían a una nueva página con el mensaje 
del lado del campo que contiene el error. La nueva página Web podría tener un vínculo a 
ayuda adicional. 

Hasta ahora, hemos discutido la retroalimentación visual en texto o de forma icónica, 
pero muchos sistemas también tienen capacidades de retroalimentación de audio. Cuando 
un usuario introduce datos incorrectos, el sistema podría emitir un sonido en lugar de pro- 
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usuario que habrá un retraso 
durante la impresión. 



porcionar una ventana. Pero la retroalimentación de audio sola no es descriptiva, de modo 
que no es útil para los usuarios como instrucciones en pantalla. Use retroalimentación de 
audio con moderación, quizás para denotar situaciones urgentes. Para el diseño de sitios 
Web también se aplica la misma sugerencia, éstos se podrían consultar en una oficina abier¬ 
ta, donde se propagan mucho los sonidos y las vocinas de los equipos de un colaborador es¬ 
tán al alcance del oído de otras personas. 


Explicando un retraso en el procesamiento Uno de los tipos más importantes de retroali¬ 
mentación informa al usuario que habrá un retraso en el procesamiento que se solicitó. Los 
retrasos de aproximadamente más de 10 segundos requieren retroalimentación para que el 
usuario sepa que el sistema aún está trabajando. 

La figura 14.11 muestra una pantalla que proporciona retroalimentación en una venta¬ 
na a un usuario que simplemente ha solicitado una impresión de la lista de suscripción del 
periódico. La pantalla muestra una frase que tranquiliza al usuario y le informa que la peti¬ 
ción se está procesando, así como también una señal en la esquina superior derecha que le 
dice al usuario que "ESPERE" hasta que el comando actual se haya ejecutado. La pantalla 
también proporciona una forma de detener la operación si es necesario. 

A veces durante los retrasos, mientras se instala el nuevo software, en la nueva aplica¬ 
ción se ejecuta un manual de instrucción corto, el cual sirve como una distracción en lugar 
de retroalimentación sobre la instalación. Con frecuencia, se usan una lista de archivos que 
se están copiando y una barra de estado para tranquilizar al usuario e infomrarle que el sis¬ 
tema está funcionando adecuadamente. Normalmente los navegadores Web despliegan las 
páginas Web que se están cargando y el tiempo de espera. 

El momento en que este tipo de retroalimentación se ejecuta es crítico. Una respuesta 
demasiado lenta del sistema podría causar que el usuario introduzca comandos que impidan 
o rompan el procesamiento. 


Reconociendo que una petición está completa Los usuarios necesitan saber cuando se 
han completado sus peticiones y podrían introducir nuevas peticiones. Con frecuencia se des¬ 
pliega un mensaje de retroalimentación específeo cuando un usuario ha completado una 
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acción, tal como "SE HA AGREGADO EL REGISTRO DEL EMPLEADO", "SE HA 
CAMBIADO EL REGISTRO DEL CLIENTE" o "SE HA ELIMINADO EL NÚMERO 
DEL ARTÍCULO 12345". 


Notificando que una petición no fue completada La retroalimentación también es necesaria 
para permitir al usuario saber que la computadora es incapaz de completar una petición. Si 
la pantalla lee "INCAPAZ DE PROCESAR LA PETICIÓN. VERIFIQUE NUEVAMENTE 
LA PETICIÓN", el usuario puede regresar entonces y verificar si la petición se introdujo 
correctamente en lugar de continuar introduciendo comandos que no se pueden ejecutar. 

Ofreciendo a los usuarios retroalimentación más detallada Los usuarios necesitan estar 
tranquilos de que la retroalimentación más detallada está disponible y deben mostrar cómo 
pueden conseguirla. Se podrían emplear comandos como Ayudar, Capacitar, Explicar o 
Más. Incluso el usuario podría teclear un signo de interrogación o apuntar a un icono apro¬ 
piado para conseguir más retroalimentación. Usar el comando Ayuda como una forma de 
obtener información más detallada se ha cuestionado, debido a que los usuarios se podrían 
sentir desprotegidos o caer en una trampa de la cual deben escapar. Esta convención está en 
uso y su familiaridad para los usuarios podría superar esta preocupación. 

Al diseñar interfaces Web, se pueden incluir hipervínculos para permitir al usuario ir a 
pantallas de ayuda relevantes o ver más información. Normalmente los hipervínculos se re¬ 
saltan con un subrayado o se italizan; también podrían aparecer en un color diferente. Los 
hipervínculos pueden ser gráficos, texto o iconos. 


INCLUSIÓN DE RETROALIMENTACIÓN EN EL DISEÑO 

El tiempo del analista de sistemas para proporcionar retroalimentación de usuario es muy 
valioso. Si se usa correctamente, la retroalimentación puede ser un refuerzo poderoso del 
proceso de aprendizaje de usuarios así como también servir para mejorar su desempeño con 
el sistema y aumentar su motivación para la producción. 

Variedad de opciones de ayuda La retroalimentación en las computadoras personales se 
ha desarrollado durante años. La "Ayuda" empezó originalmente como una respuesta al 
usuario quien presionaba una tecla de función tal como Fl; la alternativa de GUI es el me¬ 
nú de ayuda desplegable. Este enfoque era difícil, debido a que los usuarios finales tenían 
que navegar a través de una tabla de contenido o buscar mediante un índice. Después sur¬ 
gió la ayuda sensible al contexto. Los usuarios simplemente debían hacer clic con el botón 
derecho del ratón y se desplegarían temas o explicaciones acerca de la pantalla actual o 
área de la pantalla. Algunos fabricantes de software comercial los llaman fichas de opciones. 
Un tercer tipo de ayuda en las computadoras personales ocurre cuando el usuario coloca la 
flecha sobre un icono y la deja ahí durante un par de segundos. En este punto, algunos pro¬ 
gramas despliegan un globo similar al de las tiras cómicas. Este globo explica un poco sobre 
la función del icono. 

El cuarto tipo de ayuda son los asistentes, los cuales hacen una serie de preguntas a los 
usuarios y después toman una acción correspondiente. Los asistentes se han usado afinando 
una búsqueda en una enciclopedia tal como Encarta, en el diseño de un gráfico en Freelance 
o PowerPoint o al seleccionar un estilo para un memorándum de procesamiento de palabras. 

Además de construir ayuda en una aplicación, los fabricantes de software ofrecen líneas 
de ayuda (sin embargo, la mayoría de las líneas telefónicas de servicio a clientes no son gra¬ 
tuitas] . Algunos fabricantes de software comercial ofrecen un sistema de ayuda automática 
por fax. Un usuario puede pedir se le envíe mediante fax un catálogo de temas de ayuda 
disponibles y después puede pedir la documentación de un tema en particular del catálogo 
introduciendo el número del artículo con un teléfono de tonos. 

Finalmente, los usuarios pueden buscar y encontrar apoyo de otros usuarios a través de 
los foros de software y grupos de discusión. Por supuesto, este tipo de apoyo es extraoficial 
y por lo tanto la información obtenida podría ser verdadera, parcialmente verdadera o in¬ 
cluso podría desviar al usuario. Los principios con respecto al uso de foros de software son 
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los mismo para los mencionados en el capítulo 16, donde se discuten el FOLKLORE y los 
sistemas de recomendación. Lea esta sección antes de aceptar lo que se dice en los tableros 
de anuncios. [Tenga cuidado! 

Además de la ayuda informal en el software, los sitios Web del vendedor son sumamente 
útiles para actualizar controladores, visores y el propio software. La mayoría de las revistas 
de computación tienen alguna clase de "monitoreo de controladores" o "informe de errores" 
que supervisan los tableros de anuncios y sitios Web buscando programas útiles que puedan 
descargarse. Los programas analizan sitios Web del vendedor en busca de las últimas actua¬ 
lizaciones, informan al usuario de ellos, ayudan con las descargas y realmente actualizan las 
aplicaciones del usuario. 


CONSIDERACIONES ESPECIALES PARA EL DISEÑO 
DE COMERCIO ELECTRÓNICO 

Muchos de los principios del diseño de interfaz de usuario que ha aprendido acerca de la 
retroalimentación también se extienden al diseño de sitios Web de comercio electrónico. 
Unas consideraciones extras mostradas en esta sección pueden dar a sus diseños de la interfaz 
Web una mejor funcionalidad. Incluyen aprender a incorporar métodos para producir retro- 
alimentación del sitio Web de clientes del comercio electrónico y cuatro formas de propor¬ 
cionar navegación de un solo clic en los sitios de comercio electrónico que asegurarán que 
los clientes puedan navegar con facilidad en el sitio y que puedan volver prontamente a él. 

CÚiO SOLICITAR RETROALIMENTACIÓN A LOS CUENTES DE SITIOS WEB 
DE COMERCIO ELECTRÓNICO 

No sólo usted necesita proporcionar retroalimentación a los usuarios sobre lo que está pa¬ 
sando con un pedido, sino que en ocasiones también necesita solicitarla de los usuarios. La 
mayoría de los sitios Web de comercio electrónico tienen un botón Retroalimentación. Hay 
dos formas estándar para diseñar lo que verán los usuarios cuando hagan clic en el botón 
Retroalimentación. 

La primera forma es iniciar el programa de correo electrónico del usuario con la direc¬ 
ción de correo electrónico del contacto de la compañía introducido automáticamente en el 
campo ENVIARA: del mensaje. Este método previene errores de tecleo y facilita el contactar 
a la organización. El usuario no necesita dejar el sitio para comunicarse. Sin embargo, de es¬ 
tos mensajes surgen expectativas de que se contestarán sólo como correo regular o llamadas 
telefónicas. Las investigaciones indican que 60 por ciento de las organizaciones con este ti¬ 
po de forma de contacto de correo electrónico en sus sitios no tienen asignado a nadie para 
contestar los mensajes recibidos. Por lo tanto, el negocio está perdiendo retroalimentación 
valiosa, permitiendo a clientes tener la impresión de que se están comunicando y creando 
mala voluntad cuando no se recibe ninguna respuesta. Si diseña este tipo de oportunidad de 
retroalimentación, también necesita diseñar los procedimientos para que la organización 
responda a ese tipo de mensajes. 

El segundo tipo de diseño para almacenar la retroalimentación de clientes que usan un 
sitio Web de comercio electrónico es llevar a los usuarios a una plantilla de mensaje en 
blanco cuando hacen clic en Retroalimentación. Incluso una herramienta familiar tal como 
Microsoft FrontPage le permite crear e insertar con facilidad un formulario de retroalimen¬ 
tación en su sitio. Este formulario podría empezar con un título que diga "Retroalimenta¬ 
ción de la Compañía X" y después leer, "Usted puede usar el formulario debajo para 
enviar sugerencias, comentarios y preguntas sobre el sitio X a nuestro equipo de Servicio a 
clientes". 

Los campos pueden incluir el Nombre, Apellido, Dirección de correo electrónico. Con 
respecto a (un campo subjetivo que proporciona un menú desplegable del producto o de 
las selecciones de servicio de la compañía, que le piden al usuario "Por favor haga una se¬ 
lección"], una sección "Introduzca su mensaje aquí:" (un espacio libre donde los usuarios 
pueden escribir su mensaje] y los botones estándar Enviar y Limpiar en la parte inferior 
del formulario. Usar este tipo de formulario permite al analista tener los datos del usuario 
ya formateados correctamente para el almacenamiento en una base de datos. Por consi- 
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los clientes hablen entre sí, que intercambien ideas sobre los productos 


Marathón Vitamin Shops tuvo éxito para poner en funcionamiento su 
sitio Web. Los desarrolladores Web pusieron en línea todo eícatálogóde 
la compañía e incluyeron diversas máscaras de entre las cuales es posi¬ 
ble elegir, conel fin de que cada tipo de cliente disfrute al utilizar el sitio 
Web. (Vea más detalles¡en las Oportunidades de consultoría 1.1 y 12.4.) 

Los analistas están sosteniendo reuniones con Bill Berry, el propieta¬ 
rio, y con aígurios empleados para evaíúár los comentarios dé los clientes, 
y para externar sus propias opiniones sobre el sitio Web. Se encuentran 
reunidos en una enorme sala de conferencias, donde disponen de una 
computadora con acceso a Internet y un proyector. Conforme toman sus 
lugares en la mesa, la pantalla de entrada al sitio Web se proyecta al 
frente de la sala. "El sitio Web ha atraído mucha atención, pero deseamos 
ofrecer algo más a los clientes para que vuelvan constantemente", dice 
Bill, gesticulando ante la pantalla. / . v 

Continúa: "No se trata de que estemos cerrando nuestras tiendas mi¬ 
noristas ni nada parecido. De hecho, es todo lo contrario. Guándolos 
clientes se percaten de que estarnos en la Web, estarán deseosos de en¬ 
contrar la tienda de su comunidad. Ellos quieren caminar en un tienda 
y conversar con un experto capacitado en lugar de comprartodo a través 
de Internet,Necesitamos Indicarle a la gente cómo llegar ahí". 

"Creemos que podemos perfeccionar el 'sitio agregando mejoras y ca¬ 
racterísticas especiales", dice Al Falta-, miembro del equipo de sistemas que 
desarrolló e implemento originalmente el sitio Web de comercio electrónico. 

"Sí", dice Glnger Rute, miembro del equipo de desarrollo de siste¬ 
mas, al tiempo que mueve la cabeza en señal de asentimiento. "Block- 
bustery Borders utilizan un mapa de IVIapQuest, y Home Depot utiliza 
mapas dé Microsoft Vicinity, ¡que también produce MapBiast!" 

VitaMinn, otro miembro del equipo de desarrollo de sistemas origi¬ 
nal, interviene conentusiasmo: "Conocemos un par de buenos serviciosV : . 
de tableros de mensajes y salas de discusión que podemos integraren; 
nuestro sitio Web. Creemos que pueden mejorar la lealtad al sitio, estimu¬ 
lando a la gente a permanecer más tiempo en él y también a que deseen 

que regresar". : > 

"Ésa es una buena ¡dea", dice Jln Singh, uno de los empleados de 
Marathón con buenos conocimientos tecnológicos. "Podemos hacer que 


que les hayan gustado, etcétera." V 

. Vita continúa mientras se dirige al teclado de la computadora: "Per¬ 
mítanme mostrarles los sitios en www.planetgov.com y www.worídvie- 
wer.com". Mientras introduce el primer URL, el grupo ve el sitio pro¬ 
yectado. "Ellos emplean sistemas de conversación de ¡chat y 
Muiticity.com, respectivamente", agrega. 

"Los clientes también necesitan-buscar más información sobre un pro¬ 
ducto o un fabricante", dice Al. "Facilitémosles esta labor. Veamos un ejem¬ 
plo en www.Cincinnati.com. Ellos usan Atomz para buscar información.” 

• Después de escuchar atentamente, Bill interviene. "La información 
médicatambién podría ser útil", dice, "Me he dado cuenta de que www. 
medpool.com tiene noticias médicas de NewsEdge. He observado a gente 
viendo los canales financieros en las caminadoras del centro de acondi¬ 
cionamiento físico mientras hacen ejercicio." 

"Ya que estamos en esto, ¿porqué no agregamos noticias e informa¬ 
ción financiera al sitio Web?", pregunta Glnger. "Vi que www.nmm.com 
tiene noticias sobre el mercado que le proporciona una compañía conoci¬ 
da como Moreover.com. "./' 

Reflexione sobre ía conversación entre el equipo de desarrollo de sis¬ 
temas y la gente de Marathón Vitamin Shops, Algunas de las sugeren¬ 
cias implican aprovechar servicios gratuitos; otras requieren pagos'que 
van de $1,000 a $5,000 anuales. Aunque algunas ¡deas fueron buenas, 
otras no parecen factibles. Quizá algunas délas ¡deas no sean apropia¬ 
das para la compañía. 

En cada uno dejos siguientes puntos, revise lo que sabe de la misión 
y las actividades de negocios de Marathón Vitamin Shops. A continua¬ 
ción opine sobre cada opción que hayan sugerido los analistas y los 
clientes, defendiendo sus argumentos: 

: . O Software de mapas enlazados alsitio Web. 

8 Salones de conversación y tableros de mensajes. 

A ÍMotores de búsqueda. ; 

Información médica; 

9 Noticias e información sobre mercados financieros. 


guíente, esto hace que los datos introducidos en un formulario de retroalimentación sean 
fáciles de analizar en el agregado. 

Entonces, el analista no sólo diseña una respuesta para un correo electrónico individual. 
El analista ayuda a la compañía a capturar, almacenar, procesar y analizar información valiosa 
del cliente de tal forma que probablemente la compañía será capaz de descubrir las tenden¬ 
cias importantes en la respuesta del cliente, en lugar de simplemente reaccionar a consultas 
individuales. 


NAVEGACION FACIL POR LOS SITIOS WEB DE COMERCIO ELECTRONICO 

Muchos autores hablan de lo que se conoce como "navegación intuitiva" para los sitios Web 
de comercio electrónico. Los usuarios necesitan saber navegar el sitio sin tener que aprender 
una interfaz nueva y sin tener que explorar cada pulgada del sitio Web antes de que puedan 
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encontrar lo que quieren. El estándar para este tipo de enfoque de navegación se llama na¬ 
vegación de un solo clic. 

Hay cuatro formas de diseñar navegación fácil y de un solo clic para un sitio de comer¬ 
cio electrónico: (1) crear un menú rollover; (2) construir una colección de vínculos jerárqui¬ 
cos para que la página de inicio se convierta en el índice de los títulos de temas importantes 
relacionados con el sitio Web; (3) poner un mapa del sitio en la página de inicio y destacar 
el vínculo hacia él (así como también hacia las otras páginas del sitio], y (4) poner una ba¬ 
rra de navegación en cada página interior (normalmente en la parte superior o del lado iz¬ 
quierdo de la página) que repite las categorías usadas en la pantalla de entrada. 

Un menú rollover se puede crear con Java applet o con capas de JavaScript y de HTML, 
si no quiere que los usuarios ejecuten applets de Java. El menú rollover aparece cuando el 
cliente que usa el sitio Web coloca y hace reposar el indicador sobre un vínculo. 

Crear un índice del contenido del sitio a través de la presentación de una tabla de con¬ 
tenidos en la página de inicio es otra forma de acelerar la navegación del sitio. Sin embargo, 
este diseño impone restricciones severas en la creatividad del diseñador y algunas veces 
simplemente presenta una lista de temas que no lleva adecuadamente al usuario la misión 
estratégica de la organización. 

Diseñar y después desplegar de forma prominente el vínculo a un mapa del sitio es una 
tercera forma de mejorar la eficacia de navegación. Recuerde incluir el vínculo al mapa del 
sitio en la página de inicio así como también en cada página. 

Finalmente, puede diseñar barras de navegación que se desplieguen de forma consisten¬ 
te en la página de inicio así como también en la parte superior izquierda de todas las demás 
páginas que componen el sitio. Una vez que ha establecido (durante la fase de requerimien¬ 
tos de información) las categorías más útiles y más usadas (normalmente categorías tales co¬ 
mo "Nuestra compañía", "Nuestros productos", "Compre ahora", "Contártenos", "Mapa del 
sitio" y "Búsqueda"), recuerde incluirlas en todas las páginas. 

Incluir una función de búsqueda es otra opción. Las extensiones de Microsoft Front- 
Page, al igual que las de otros paquetes de software tienen integradas las capacidades de 
búsqueda; otras posibilidades incluyen agregar a su sitio un motor de búsqueda tal como 
Google. Las funciones de búsqueda simples están bien para los sitios pequeños y maneja¬ 
bles, pero conforme crece un sitio, se necesitan funciones de búsqueda avanzadas que inclu¬ 
yan lógica buliana (discutida más adelante en este capítulo). 

Sin embargo, la prioridad principal en la navegación es que no importando lo que se 
haga, debe ser muy sencillo para un usuarios el regresar a la página anterior, y ser relativa¬ 
mente fácil el regresar al lugar donde el usuario entró al sitio inicialmente. Su principal 
problema es mantener a los clientes en el sitio Web. Entre más clientes haya en el sitio, ma¬ 
yor será la oportunidad de que compren uno de los productos que se ofrecen allí. De tal 
manera, asegúrese que si los usuarios navegan a un vínculo en el sitio Web de su cliente, 
puedan encontrar con facilidad la forma de regresar. Hacer estas cosas asegurará la lealtad 
y permanencia en el sitio Web. No cree ninguna barrera para el cliente que quiere regresar 
al sitio Web. 


DISEÑO PE CONSULTAS 

Cuando los usuarios hacen preguntas de la base de datos o se comunican con ella, dicen que 
la consultan. Hay seis tipos diferentes de consultas más comunes. 


TIPOS DE CONSULTA 


Las preguntas que proponemos acerca de los datos de nuestra base de datos se denominan 
consultas. Hay seis tipos básicos de consultas. Cada consulta involucra tres artículos: una en¬ 
tidad, un atributo y un valor. En cada caso, se dan dos de éstos y la intención de la consulta 
es encontrar el artículo restante. La figura 14.12 se usará para ilustrar todos los ejemplos de 
consulta. 
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Es: posible desempeñar seis tipos 
básicos de consultas en una,; ■/')_ 
tabla que contiene entidades, 
atributos y valores. 


Tipo de consulta 1 En el primer tipo de consulta, se dan la entidad y uno de los atributos 
de ésta. El propósito de la consulta es encontrar el valor. La consulta se puede expresar co¬ 
mo sigue: 

¿Cuál es el valor de un atributo especial para una entidad particular? 

A veces es más conveniente usar una notación para ayudar a formular la consulta. Esta con¬ 
sulta se puede escribir como 


V*-[E,A) 

donde Urepresenta el valor, E la entidad y A el atributo, y se dan las variables en los parén¬ 
tesis. 

La pregunta 

¿Qué hizo el número de empleado 73712 en el año 2003? 

se puede declarar más específicamente como 

¿Cuál es el valor del atributo AÑO 2003 para la entidad NÚMERO DE EMPLEA¬ 
DO 73712? 

El registro que contiene el número de empleado 73712 se encontrará y la respuesta a la 
consulta será "$47,100". 

Tipo de consulta 2 El propósito del tipo de consulta 2 es encontrar una entidad o enti¬ 
dades cuando se dan un atributo y un valor. El tipo de consulta 2 se puede declarar como 
sigue: 

¿Qué entidad tiene un valor especificado para un atributo particular? 

Debido a que los valores también pueden ser numéricos, es posible buscar un valor igual a, 
mayor que, menor que, diferente a, mayor o iguala a, etc. Un ejemplo de este tipo de con¬ 
sulta es como sigue: 

¿Qué empleado[s) ganó (ganaron) más de $50,000 en 2003? 

La notación para el tipo de consulta 2 es 
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En este caso, tres empleados ganaron más de $50,000, de modo que la respuesta será una 
lista del número de empleado para los tres empleados: "72845, 72888 y 80345". 

Tipo de consulta 3 El propósito del tipo de consulta 3 es determinar qué atributo(s) satis¬ 
face la descripción proporcionada cuando se dan la entidad y el valor. El tipo de consulta 3 
se puede declarar como sigue: 

¿Qué atributo(s) tiene un valor especificado para una entidad particular? 

Esta pregunta es útil cuando hay muchos atributos similares que tienen la misma propie¬ 
dad. El ejemplo siguiente tiene atributos similares (los años específicos] que contienen los 
salarios anuales para los empleados de la compañía: 

¿En qué años el número de empleado 72845 ganó más de $50,000? 

o, para ser más preciso, 

¿Qué atributos {AÑO 2000, AÑO 2001, AÑO 2002, AÑO 2003} tienen un valor 
> 50,000 para la entidad NÚMERO DE EMPLEADO = 72845? 

donde la lista opcional en las llaves { } es el juego de atributos elegibles. 

La notación para el tipo de consulta 3 es 

A ir- [V, E) 

En este ejemplo, Waters (número de empleado 72845] ganó más de $50,000 durante 
dos años. Por consiguiente, la respuesta será "año 2001 y año 2003". El tipo de consulta 3 es 
más raro que el tipo 1 o el tipo 2 debido al requerimiento de tener atributos similares que 
exhiben las mismas propiedades. 

Tipo de consulta 4 El tipo de consulta 4 es similar al tipo de consulta 1. La diferencia es 
que los valores de todos los atributos son deseados. La consulta 4 se puede expresar como 
sigue: 

Mencione todo los valores de todos los atributos para una entidad particular. 

Un ejemplo del tipo de consulta 4 es el siguiente: 

Mencione todos los detalles en el archivo de historial de ingresos para el número 
de empleado 72888. 

La notación para el tipo de consulta 4 es 

todos los V <— (£, todos los M) 

La respuesta para esta consulta será el registro entero para el empleado llamado Dryne 
(número de empleado 72888]. 


Tipo de consulta 5 El quinto tipo de consulta es otra consulta global, pero es similar al ti¬ 
po de consulta 2. El tipo de consulta 5 se puede declarar como sigue: 

Mencione todas las entidades que tienen un valor especificado para todos los 
atributos. 

Un ejemplo del tipo de consulta 5 es el siguiente: 

Mencione todos los empleados cuyos ingresos excedieron $50,000 en cualquiera 
de los años disponibles. 

La notación para el tipo de consulta 5 es 

todas las E <— [V, todos los A) 


La respuesta para esta consulta será "72845, 72888 y 80345". 
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Tipo de consulta 6 El sexto tipo de consulta es similar al tipo de consulta 3. La diferencia 
es que el tipo de consulta 6 solicita una lista de los atributos para todas las entidades en lu¬ 
gar de una entidad particular. El tipo de consulta 6 se puede declarar como sigue: 

Mencione todos los atributos que tienen un valor especificado para todas las enti¬ 
dades. 

El siguiente es un ejemplo del tipo de consulta 6: 

Mencione todos los años en que los ingresos excedieron $40,000 para todos los 
empleados de la compañía. 

La notación para el tipo de consulta 6 es 

todos los A <— (V, todas las E] 

La respuesta será "AÑO 2001, AÑO 2002 y AÑO 2003". Al igual que el tipo de consulta 3, 
el tipo de consutla 6 no se usa tanto como otros tipos. 

Construcción de consultas más complejas Los seis tipos de consulta anteriores únicamen¬ 
te son elementos esenciales para las consultas más complejas. Las expresiones denominadas 
como expresiones booleanas se pueden formar para las consultas. Un ejemplo de dicha ex¬ 
presión es el siguiente: 

Mencione a todos los clientes que tienen códigos postales mayores que o iguales a 
60001 y menores que 70000, y quienes han pedido más de $500 en productos de 
nuestros catálogos o que han realizado al menos cinco pedidos en el último año. 

Una dificultad con esta declaración es determinar qué operador [por ejemplo. Y) junto 
con qué condición; también es difícil determinar la secuencia en que las partes de la expre¬ 
sión se deben llevar a cabo. Lo siguiente podría ayudar a aclarar este problema: 

LISTE A TODOS LOS CLIENTES QUE TIENEN (CÓDIGO POSTAL MAI 
60001 Y CÓDIGO POSTAL MEQ 70000) Y (CANTIDAD PEDIDA MAQ 500 
O VECES PEDIDAS MAI 5] 

Ahora se elimina alguna confusión. La primera mejora es que los operadores se expre¬ 
san con mayor claridad como MAI, MEQ y MEI (mayor o igual, menor que, menor o igual) 
en lugar de frases en lenguaje natural, tal como "por lo menos". Segundo, a los atributos se le 
dan nombres diferentes, como CANTIDAD PEDIDA y VECES PEDIDAS. En la frase an¬ 
terior, estos atributos se denominaban como "han pedido". Por último, los paréntesis se usan 
para indicar el orden en que se desempeña la lógica. Cualquier cosa que esté en los parén¬ 
tesis se hace primero. 

Generalmente las operaciones se desempleñan en un orden predeterminado de prece¬ 
dencia. Normalmente las operaciones aritméticas se desempeñan primero (exponencia- 
ción, después multiplicación o división y al final suma o resta). Después, se desempeñan las 
operaciones comparativas. Estas operaciones son MAQ (mayor que), MEQ (menor que) y 
otras. Finalmente, se desempeñan las operaciones booleanas (primero Y y después O). En el 
mismo nivel, normalmente el orden va de izquierda a derecha. En la figura 14.13 se resume 
la precedencia. 

MÉTODOS DE CONSULTA 

Dos métodos de consulta populares son consulta mediante ejemplo y lenguaje de consultas 
estructurado. 

Consulta mediante ejemplo La consulta mediante ejemplo (denominada CME) es un mé¬ 
todo simple pero poderoso para implementar las consultas en los sistemas de base de datos, 
tal como Microsoft Access. Los campos de la base de datos se seleccionan y despliegan en 
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Los operadores aritméticos, 
comparativos y booleanos se 
procesan en un orden jerárquico 
de precedencia a menos que se 
usen paréntesis. 


Operadores aritméticos 


Operadores comparativos 


Operadores booleanos 


2 *; i I 

4 MAQ MEO 

INI 

MAI MEI 

5 Y 

6 0 


una cuadrícula y los valores de consulta solicitados se introducen en el área del campo o 1 de¬ 
bajo del campo. La consulta debe poder seleccionar ambas filas de la tabla que hace coinci¬ 
dir las condiciones así como también las columnas específicas (campos). Las condiciones 
complejas se podrían establecer para seleccionar registros y el usuario podría especificar con 
facilidad las columnas a ser ordenadas. La figura 14.14 es un ejemplo de consulta mediante 
ejemplo que usa Microsoft Access. La pantalla de diseño de consulta se divide en dos partes. 
La parte superior contiene las tablas seleccionadas para la consulta y sus relaciones y la parte 
inferior contiene la cuadrícula de selección de consulta. Los campos de las tablas de la base 
de datos se arrastran a la cuadrícula. 

Las primeras dos filas contienen el campo y la tabla en que se localiza el campo. La si¬ 
guiente fila contiene la información en orden. En este ejemplo, los resultados se ordenarán 
por NOMBRE DE CLIENTE. Una marca de verificación en el cuadro Mostrar (cuarta fila 
hacia a abajo) indica que el campo será desplegado en los resultados. Observe que el NÚ¬ 
MERO DE CLIENTE, NOMBRE DE CLIENTE y SIGNIFICADO DE CÓDIGO DE ES¬ 
TADO se seleccionan para la pantalla resultante (también se despliegan otros campos, pero 
no se muestran en la pantalla). Observe que el CÓDIGO DE ESTADO DE CUENTA y el 
CÓDIGO DE TIPO DE CUENTA no tienen marca de verificación y por lo tanto no estarán 
en los resultados finales. En las filas de Criterios, hay un 1 en el CÓDIGO DE ESTADO 


FIGUSA 14 14 

La consulla mediante ejemplo 
usando Microsoft Access. 
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HEY, MÍRAME ...(OTRA VEZ) 


Le hablaron de Merman's Costume Rentáis para que les haga otra vi 1 
sita. Aquí se muestra una parte de la base de datos que generó Anníe 
Oaklea, de Merman's {con quien usted trabajó en las Oportunidades de 
consultaría 7.1 y 8.1). La base de datos contiene información, como el cos¬ 
to de una renta, la fecha en que se devolvió, la fecha de vencimiento y los 
días que se ha rentado el disfraz desde el comienzo del año (DÍAS REN¬ 
TADOS HLF) (véase la figura 14.C1). •/ 

Al analizar un día típico de Annie en el negocio de la renta de disfra¬ 
ces, usted se da cuenta de que hay diversas solicitudes que ella debe 
hacer a la base de datos con el fin de tomar decisiones relativas a cuán¬ 
do reemplazar los disfraces más utilizados, o incluso cuándo comprar 


más disfraces de un tipo específico. También tiene que recordar a los 
clientes a quienes les ha tenido que negar la renta de un disfraz especí¬ 
fico, tiene que saber cuándo llamar para avisar que ha vencido la renta 
de un disfraz, etcétera. 

Elabore diversas consultas que ayudarán a Annie a conseguir la in¬ 
formación que necesita de la base de datos. {Sugerencia: haga las supo¬ 
siciones que sean necesarias acerca de los tipos de información que ella 
requiere para tomar decisiones y utilice los diferentes tipos de consultas 
que se han explicado en este capítulo.) Describa en un párrafo en qué 
diferirían las consultas si Annie estuviera trabajando con un sistema 
basado en Web o uno hipervinculado. 
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Parte de la base de datos de la tienda Merman's Costume Rehtal. 


DE CUENTA (que indica un registro activo) y en las columnas CÓDIGO DE TIPO DE 
CUENTA hay una C y una D (que seleccionan un Cliente general o un Cliente con des¬ 
cuento). Dos condiciones en la misma fila indican una condición AND y dos condiciones en 
filas diferentes representan una condición OR. Esta consulta especifica que el usuario debe 
seleccionar a un Cliente activo y a un Cliente general o con descuento. 

En la figura 14.15 se ilustran los resultados de una consulta que se despliegan en una 
tabla. Observe que el CÓDIGO DE ESTADO DE CUENTA y el CÓDIGO DE TIPO DE 
CUENTA no se despliegan. Estos no están marcados y únicamente se incluyen en la con- 
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sulta para propósitos de selección. En cambio, se despliegan los significados del código, los 
cuales son más útiles para el usuario. Los nombres de cliente están en orden alfabético. 

Uno de los problemas encontrados al diseñar las consultas es que el usuario debe mo¬ 
dificar los parámetros de la consulta o cada vez que ésta se ejecute se seleccionarán las 
mismas condiciones. Una solución a este problema es usar una consulta mediante paráme¬ 
tros. Este tipo de consulta permite al usuario introducir las condiciones en un cuadro de 
diálogo cada vez que la consulta se ejecute. En la figura 14.16 se ilustra una consulta me- 
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Un cuadro de .diálogo para 
ingresar consultas mediante 
parámetros. 


diante parámetros. Observe que los criterios tienen el mensaje "Introduzca un Nombre de 
cliente parcial" incluido en los corchetes. Antes del mensaje está la palabra "Parecido" y des¬ 
pués del mensaje hay un ampersand que indica que no se requiere una coincidencia exacta. 
Cuando se ejecuta la consulta, se abre un cuadro de diálogo con el mensaje de consulta en 
la parte superior. Consulte la figura 14.17. Se introduce el valor "ma" y se usa para seleccio¬ 
nar el nombre. En la figura 14.18 se despliegan los resultados. Observe que sólo se seleccionan 
y despliegan los clientes cuyos nombres empiezan con las letras "ma". 

Lenguaje de consultas estructurado El lenguaje de consultas estructurado (SQL) es 
otra forma popular para implementar consultas. Usa una serie de palabras y comandos 
para seleccionar las filas y columnas que se deben desplegar en la tabla resultante. La fi¬ 
gura 14.19 ilustra el código SQL que es equivalente a la consulta de parámetros mostra¬ 
da anteriormente. La palabra clave SELECCIONAR LILADISTINTA determina qué fi¬ 
las serán seleccionadas. La palabra clave DONDE especifica la condición que debe usar 
el NOMBRE DE CLIENTE para seleccionar los datos introducidos en el parámetro 
PARECIDO. 

La figura 14.20 es un ejemplo del código SQL usado para producir los resultados 
que hacen coincidir la consulta mediante un ejemplo. Observe que hay palabras clave 
adicionales que incluyen la relación entre las tablas (UNION INTERNA) y también 
que la lógica Y y O se incluye en paréntesis para permitir la evaluación correcta de las 
condiciones. El parámetro PEDIDO POR indica la secuencia de ordenamiento de la tabla 
resultante. 
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¿FMSURA 14.19 


Lenguaje de consultas 
estructurado (SQL) para la 
consulta mediante parámetros 
NOMBRE DE CLIENTE. 


SELECCIONAR FILADISTINTA 

Cliente.fNúmero de cliente], 

Cliente.JNombre de cliente], • 

Cliente.Ciudad, é 

Cliente.Teléfono 
DEL Cliente 

DONDE (((Cliente.INombre de cliente]) 

Parecido ([Introduzca un nombre de cliente parcial]&"*"))); S;¿ 



BÚSQUEDA EN LA WEB 

Es imposible discutir las consultas sin hablar sobre la búsqueda en la Web o Internet. Los 
motores de búsqueda básicamente son bases de datos accedidas por un usuario para buscar 
información. Los URLs almacenados en la base de datos se obtienen de diferentes formas 
que dependen del motor de búsqueda. Algunos motores de búsqueda se basan en gran me¬ 
dida en un buscador Web (o robot], el cual actúa como un agente inteligente que navega en 
la Web buscando los URLs apropiados. Otros motores de búsqueda se basan en la intere- 
vención humana. Un tercer enfoque es listar URLs de sitios Web para los cuales los dueños 
pagan para ser listados. 

En el momento en que este libro se escribió, el motor de búsqueda principal era Goo- 
gle (www.google.com). Google obtiene principalmente sus resultados de búsqueda de un 
buscador Web. AOL Search y Netscape son motores de búsqueda que reciben la mayoría de 
sus resultados de Google. Los competidores de Google que principalmente dependen de los 
buscadores Web son AltaVista, Ask Jeeves y Teoma. 

Dos motores de búsqueda dependen en exceso de listas compiladas por los humanos. 
Éstos son Open Directory y LookSmart. El motor de búsqueda principal basado en los re¬ 
sultados pagados es Overture. Desde su introducción en 1998, Google ha introducido 
búsquedas que incluyen resultados pagados. Sin embargo, recuerde que la industria del 
motor de búsqueda en la Web cambia con rapidez. Algunos motores de búsqueda se han 
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Comandos del Lenguaje de 
Consultas Estructurado para 
la consulta ESTADO DE CUENTE. 


SELECCIONAR FILADISTINTA 

Cliente. [Número de cliente], 
Cliente. [Nombre de cliente], 


[Códigos de estado de cuenta].[Signíficado de código de estado], 
[Códigos de tipo de cuenta].[Significado de código de tipo], 
Cliente.Ciudad. 

Cliente.Teléfono 
E [Códigos de tipo de cuenta] 

JIQN INTERNA ([Códigos de estado de cuenta] 


UNION INTERNA Cliente 

EN [Códigos de estado de cuenta].[Códígo de estado de cuenta] 
= Cliente. [Código de estado de cuenta]) 

EN [Códigos de tipo de cuenta].[Código de tipo de cuenta] 

= Cliente.fCódlgo de tipo de cuenta] 


((fCIiente.fCódigo de estado de cuenta' 
Y ((Cliente.fCddigo de tipo de cuenta])="l 
PEDIDO POR Cliente.fNombre de cliente]; 
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comprado por otros motores de búsqueda. El nombre podría ser el mismo, pero el mecanis¬ 
mo del motor de búsqueda podría haber sido reemplazado. 

La aplicación Copenic Agent Professional puede ser sumamente útil. Copenic le per¬ 
mitirá crear búsquedas personalizadas basadas en una biblioteca de más de 1,000 motores 
de búsqueda. Le ayudará a dar seguimiento a las páginas Web que han tenido cambios y en¬ 
viará por correo electrónico la notificación de dichos cambios. También puede llevar un his¬ 
torial de sus búsquedas. 


LINEAMIENTOS PARA BUSCAR EN LA WEB 

Puede mejorar sus oportunidades de encontrar lo que quiere al seguir algunas de estas es¬ 
trategias: 

1. Decida si realmente quiere buscar o navegar. Si sabe qué información quiere, use un 
motor de búsqueda, tal como Google que encontrará sitios específicos. [Si quiere nave¬ 
gar, use un servicio de directorio Web tal como Yahool 

2. Piense en sus condiciones importantes antes de que se siente a la computadora. Nor¬ 
malmente es mejor diseñar que reaccionar. 

3. Construya sus preguntas de búsqueda lógicamente. ¿Está buscando "decisión" Y "sopor¬ 
te" en lugar de "decisión" O "soporte" [conseguirá resultados muy diferentes)? ¿Quiere 
encontrar todos los sitios que contienen "decisión", "soporte" y "sistemas" o está buscan¬ 
do una frase "sistemas de apoyo a la toma de decisiones"? Debe permitir al motor de 
búsqueda saber sus intenciones. ¿Qué pasa cuando introduce "DSS"? (Consigue mucha 
información sobre los sistemas de satélite directos y un poco sobre los sistemas de apo¬ 
yo a la toma de decisiones.) 

4. Use un motor de metabúsqueda que guarde y recuerde sus búsquedas. 

5. Use un motor de búsqueda que le informe de cambios en los sitios Web que seleccione. 

6. Recuerde que el negocio del motor de búsqueda es muy competitivo. Inspeccione los 
motores de búsqueda periódicamente. Encontrará que algunos motores de búsqueda 
que no poseyeron una característica en una versión anterior han sacado una actualiza¬ 
ción mejorada como consecuencia. Esta nueva versión podría superar con facilidad al 
líder anterior. 


MINERÍA DE "DATOS 

El concepto de minería de datos vino del deseo de usar una base de datos para seleccionar 
y dirigirse de manera más selectiva a los clientes. Los primeros enfoques del correo directo 
incluyeron el uso de la información del código postal como una forma de determinar lo 
que podría ser el ingreso de una familia (asumiendo que una familia debe generar el ingreso 
suficiente para poder vivir en el prestigioso código postal 90210 de Beverly Hills o algún 
otro barrio opulento). Era una forma (no perfecta, claro) para limitar el número de catálogos 
enviados. 

La minería de datos lleva este concepto un paso más allá. Asumiendo que la conducta 
del pasado es un buen predictor para las compras del futuro, una cantidad considerable de 
datos sobre una persona se recopila de, por ejemplo, compras con tarjeta de crédito. La 
compañía puede saber en qué almacenes vamos a comprar, lo que hemos comprado, cuán¬ 
to pagamos por un artículo y con qué frecuencia viajamos. También se introducen datos, se 
guardan y se usan para una variedad de propósitos cuando llenamos las tarjetas de garantías, 
solicitamos una licencia para manejar, respondemos a una oferta gratuita o solicitamos una 
tarjeta de membresía en una tienda de renta de vídeos. Es más, las compañías comparten es¬ 
tos datos y a menudo también ganan dinero por la venta de ellos. La figura 14.21 ilustra el 
concepto de minería de datos. 

American Express ha sido un líder en la minería de datos con propósitos de marketing. 
American Express le enviará cupones de descuento para nuevas tiendas o eventos de entre¬ 
tenimiento cuando le envía una factura de tarjeta de crédito, después de haber determinado 
que usted ha ido de compras en tiendas similares o ha asistido a eventos similares. General 
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La minería de dalos recopila 
información personal acerca 
de los clientes en un Intento 
por ser más específico en la 
interpretación y especificación 
de sus preferencias. 



Motors ofrece una MasterCard que permite a los clientes acumular puntos para la compra 
de un nuevo automóvil, y a continuación manda información sobre nuevos vehículos cuan¬ 
do es más probable que un consumidor se interese por comprar un nuevo automóvil. El 
proceso de la minería de datos incluye el uso de poderosas supercomputadoras que proce¬ 
san bases de datos bastante grandes —o almacenes de datos— usando técnicas como las re¬ 
des neurales (véase el capítulo 10). 

Sin embargo, el enfoque de minería de datos no está exento de problemas. Primero, los 
costos pueden ser demasiado altos para justificar la minería de datos, algo que pudiera des¬ 
cubrirse cuando ya se acumularon los enormes costos de la configuración inicial. Segundo, 
la minería de datos se tiene que coordinar para que los distintos departamentos o subsidia¬ 
rias no traten de acceder al cliente al mismo tiempo. Además, los clientes podrían pensar 
que se está invadiendo su privacidad y resentir las ofertas que se les envíe de esta manera. 
Finalmente, los clientes podrían pensar que los perfiles creados solamente con base en sus 
compras con tarjeta de crédito presentarían una imagen distorsionada de ellos. 

Hace varios años surgieron algunos problemas relativos a invasión de derechos civiles 
cuando se descubrió que las autoridades policiacas de Inglaterra observaban a los ciudada¬ 
nos en sus vecindarios, hacían suposiciones sobre la gente con base en su comportamiento 
observado y guardaban esa información en bases de datos secretas. Otros policías tenían 
acceso a estos registros, y las suposiciones quedaron sólo en eso, porque esos registros nun¬ 
ca fueron vistos o revisados por los ciudadanos "sospechosos" y nunca fueron validados por 
otros tipos de datos. Se crearon perfiles erróneos, se guardaron, se utilizaron y no se elimi¬ 
naron. Incluso en una democracia, la minería de datos tiene aplicaciones más allá de los es¬ 
fuerzos válidos del marketing para llegar a nosotros con el producto más reciente. 

Los analistas deben tomar la responsabilidad de considerar los aspectos éticos de cual¬ 
quier proyecto de minería de datos que se proponga. Preguntas sobre el tiempo que se 
conservará el material de los perfiles, la confidencialidad de éste, las garantías de privacidad 
incluidas y los usos que se darán a las inferencias se deben preguntar y considerar con el 
cliente. Las oportunidades para el abuso son evidentes y es necesario tomar medidas de pro¬ 
tección. Para los consumidores, la minería de datos es otra tecnología de envío de informa¬ 
ción automática, y si los consumidores no quieren que ésta se aplique a ellos, los esfuerzos 
de minería de datos serán contraproducentes. 
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PERDIDA DE CLIENTES POTENCIALES 


"La participación de mercado puede ser un verdadero problema", dice 
Ryan Taylor, director de Sistemas de Marketing de una enorme compañía 
de seguros médicos de la Costa Este. "Uno de los retos más granees cue 
enfrentamos es cómo identificar buenos contactos para nuestra gente de 
ventas. Con más de 50 por ciento de participación de mercado, debemos 
eliminar los nombres de la mayoría de los clientes potenciales que com- , 
pramos antes de poblar nuestra base de datos dé marketing. Es muy im- : 
portante que la tengamos en orden porque nuestra base de datos de 
marketing es una parte crucial del arsenal de herramientas de informa- . 
ción estratégicas de nuestra compañía." 

Ryan explica a Chander, uno de los miembros de su equipo de análisis 
de sistemas: "Una base de datos de marketing, o MDB para abreviar, es 
una poderosa base de datos relaciona! que es el corazón de los sistemas 
de marketing. Nuestra base de datos de marketing es utilizada para 
ofrecer información a todos los sistemas de marketing. Incluye herra¬ 
mientas de productividad, como nuestros Sistemas de Automatización 
de la Fuerza de Ventas y los de Envío Masivo de Correos, diseñadas para 
ayudar a nuestra gente de ventas en la administración del ciclo de ven¬ 
tas. También incluye herramientas analíticas, como nuestros sistemas 
de información geográfica (GIS) o herramientas de lenguajes de consulta 
gráficos (GQL), diseñadas para ofrecer apoyo a la toma de decisiones". 

"Sin embargo, la principal función de una base de datos de marketing 
es dar seguimiento a la información sobre nuestros clientes y clientes 
potenciales. Actualmente damos seguimiento a información geográfica, 
demográfica y psicográfica, o,:como me gusta decir, dónde viven, quié¬ 
nes son y cómo piensan." 

"Las bases de datos de marketing más sencillas se pueden hacer 
con sólo tres archivos: Perfil,de clientes potenciales, Perfil de clientes e 
Historial de compras y pagos."- 'LvV' 

"Una vez que ha diseñado su base de datos de marketing, el siguien¬ 
te reto es decidir cómo poblarla. En. la actualidad nosotros compramos la 
información sobre nuestros clientes potenciales a un vendedor de listas. 
Debido a que la estrategia de marketing de nuestra empresa se oasa en 
el marketing masivo, compramos información sobretodos las empresas 
de la región. Gracias a este volumen,, pagamos menos de 10: centavos ... 
porcada cliente potencial. Sin embargo, si una compañía practica la di¬ 
ferenciación de productos, probablemente su base de datos de clientes 
potenciales será más detallada. Quizá esta compañía pagaría un extra por 
datos más detallados que hayan sido comprobados de manera cuidado¬ 
sa”, explica Ryan. 

"Nosotros enfrentamos un verdadero reto. Si me dieran un dólar por 
cada vez que un representante se queja de la dirección equivocada de un 


cliente potencial, me podría jubilar y mudarme a Florida", dice Ryan sar¬ 
cásticamente. "Se supone que yo debo identificar cuáles clientes poten¬ 
ciales están mal. Esto; no sería muy difícil si sólo tuviera unos mil, ¿pero 
qué se puede hacer cuando son casi un cuarto de millón de clientes po¬ 
tenciales?" 

Ryan continúa: "Debido a que utilizamos estos datos con frecuencia 
para los envíos masivos de correo, es muy importante que nos aseguremos 
que los nombres y las direcciones dé ese archivo sean los más. precisos 
posible. Por ejemplo, tienen que apegarse a las normas postales y no de¬ 
ben, ir duplicados,' 1 , 

"Esto lo conseguimos mediante una técnica conocida como higiene 
de datos. ¿Qué significa esto? Por lo general, la higiene de datos se rea¬ 
liza con software especializado, que se emplea para determinar la vali¬ 
dez de una dirección. Este software compara la dirección de la base de 
datos con su propia base de datos interna de rangos válidos de calles y 
números de una ciudad o código postal específicos." 

Ryan prosigue: "Otro de los retos que enfrentan los especialistas en 
marketing es eliminar registros duplicados en la base de datos de mar¬ 
keting. Son dos los tipos de duplicados que buscamos: duplicados inter¬ 
nos, que son-múltiples registros del mismo cliente o cliente potencial, y 
duplicados externos, que representan nuestra incapacidad de eliminar 
clientes de los datos sobre nuestros clientes potenciales." 

"Los duplicados internos crean problemas en la elaboración de in¬ 
formes e incrementan los costos del envío de correo. Los duplicados 
externos son todavíá peores; son tanto costosos como embarazosos", 
exolica Ryan. "Una ce las situaciones más embarazosas para un re- 
presentahte de ventas es hacer una llamada a un cliente potencial y 
énterarse de que ya es un cliente nuestro. El cliente se queda con la 
sensación de que para nosotros es sólo un número en una de nuestras 
computadoras. Esto genera una mala impresión y desperdicia tiempo y 
recursos valiosos." 

Describa en dos párrafos algunas técnicas que Ryan podría usar 
para identificar duplicados internos y externos en la base de datos de 
marketing de su compañía. Éxplique en un párrafo cómo podría cons¬ 
truir usted una base de datos de marketing para minimizar los dupli¬ 
cados. ¿Existen métodos operativos mediante los cuales se podría 
reducir este problema? Menciónelos. ¿Quién más en la organización 
podría ayudaren este proceso? Elabore una breve lista. En un párra¬ 
fo. sugiera métodos a Chandler y a los demás miembros de su equipo 
de análisis de sistemas que se puedan utilizar para incluir y garanti¬ 
zar la colaboración de otros miembros importantes de la organiza- 


RESUMEN 

Nos hemos enfocado en los usuarios del sistema, su interacción con la computadora, su ne¬ 
cesidad de retroalimentación, diseñar retroalimentación del sitio Web de comercio electró¬ 
nico y navegación y el diseño de consultas de la base de datos. El éxito de los sistemas que 
diseñe depende del involucramiento y aceptación del usuario. Por consiguiente, pensar so¬ 
bre los usuarios en una forma sistemática y empática es de suma importancia y no es un 
problema periférico para los analistas de sistemas. 
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"No tengo inconveniente en usar un ratón, o cualquier otro roedor que ponga en mi camino. 
Sin embargo, en verdad, yo trato de hacer cualquier cosa que necesite Snowden. No obstan¬ 
te, cada quien es diferente. He visto gente aquí que hace todo lo que está a su alcance para 
evitar el uso de una computadora. Otros preferirían no hablar con un humano. De hecho, 
serían tan felices como una mascota jugando con una pantunfla nueva si pudiran usar un 
lenguaje de comandos para interactuar. Tengo la impresión que preferirían no hablar para 
nada con la gente, pero esto es únicamente lo que yo creo. La mayoría de nuestros compa¬ 
ñeros son abiertos a nuevas cosas. De otra forma nunca hubieran ingresado aquí a MRE. Es¬ 
tamos orgullosos de nuestra creatividad. Le he conseguido una reunión con gente del grupo 
de Capacitación, incluyendo a Tom Ketcham, Melissa Smith y Kathy Blandford. Usted puede 
invitar a quien considere que deba incluirse. También podría estar Snowden, si tiene tiempo. 
Supongo que por eso él me pidió que le entregara el mensaje. Ellos tendrán bastante curio¬ 
sidad por ver el tipo de interfaz que usted les sugerirá para el nuevo sistema de elaboración 
de informes del proyecto." 

PREGUNTAS DE HYPERCASE 

1. Escriba una breve propuesta donde describa el tipo de interfaz de usuario que sería 
apropiada para los usuarios del sistema de elaboración de informes del proyecto que es¬ 
tán en el grupo de Capacitación. Incluya las razones por las cuales tomó esta decisión. 

2. Diseñe una interfaz de usuario mediante una herramienta CASE, como Visible Analyst, 
un paquete de software como Microsoft Access o formularios en papel. ¿Cuáles son las 
características principales que resuelven las necesidades de la gente del grupo de Ca¬ 
pacitación? 

3. Demuestre su interfaz a un grupo de estudiantes que tomen los roles de los miembros 
del grupo de Capacitación. Pídales sus opiniones. 

4. Rediseñe la interfaz con base en la retroalimentación que haya recibido. Describa en 
un párrafo la manera en que su nuevo diseño tomó en cuenta los comentarios que haya 
recibido. 




En Hypercase usted puede ver corno procesa información el usuario para crear una interfaz 
de usuario más eficaz. 









En este capítulo se trataron una variedad de interfaces de usuario y dispositivos de en¬ 
trada. Algunas interfaces son particularmente adecuadas para los usuarios inexpertos, tal 
como lenguaje natural, pregunta y respuesta, menús, formulario y formulario que se basa en 
la Web, las interfaces gráficas de usuario (sobre todo en las páginas Web), el ratón, lápiz óp¬ 
tico, lápiz, pantallas sensibles al tacto y sistemas de reconocimiento de voz. El lenguaje de 
comandos funciona mejor para los usuarios con experiencia. 

Las combinaciones de interfaces pueden ser sumamente eficaces. Por ejemplo, usar me¬ 
nús desplegables con interfaces gráficas de usuario o emplear menús anidados en interfaces 
de pregunta y respuesta produce combinaciones interesantes. Cada interfaz posee un nivel 
diferente de desafío para los programadores, siendo el lenguaje natural el más difícil de pro¬ 
gramar. La Web ha presentado nuevos desafíos para diseñadores, debido a que el usuario no 
es conocido. El diseño de Web toma ventaja de los hipervínculo para permitir a usuarios to¬ 
mar varias rutas conforme interactúen con el sitio Web. 

La necesidad de usuarios por la retroalimentación del sistema también es una conside¬ 
ración importante. La retroalimentación del sistema es necesaria para permitir a usuarios sa¬ 
ber si su entrada es aceptada, si la entrada es correcta o incorrecta, si el procesamiento sigue 
adelante, si las peticiones se pueden o no procesar y si está disponible información más de¬ 
tallada y cómo conseguirla. Por lo regular la retroalimentación es visual, con texto, gráficos 
o iconos que se usan. La retroalimentación de audio también puede ser eficaz. 

Las consideraciones especiales se aplican para el diseño de sitios Web de comercio elec¬ 
trónico. Construir funcionalidad mejorada en la aplicación produciendo retroalimentación 
del cliente a través de los botones de retroalimentación por correo electrónico automático o 
mediante incluir formularios de retroalimentación en blanco en el sitio Web. 

Además, cuatro estrategias importantes de diseño de navegación mejoran la tenacidad 
de los sitios Web de comercio electrónico: menús rollover, despliegues jerárquicos de víncu¬ 
los en la pantalla de entrada, mapas del sitio y barras de navegación que proporcionan nave¬ 
gación de un solo clic que hace la navegación del sitio y el regreso al sitio tan fácil como sea 
posible para el cliente. 

Las consultas se diseñan para permitir a usuarios extraer datos significativos de la base 
de datos. Hay seis tipos básicos de consultas y se pueden combinar usando lógica booleana 
para formar consultas más complejas. 

Algunos de los principios sobre consultas de datos que aprendió se pueden usar en las 
búsquedas Web. Las herramientas de búsqueda de Internet se llaman motores de búsqueda. 
Los usuarios pueden ser más eficaces si las búsquedas se diseñan cuidadosamente y estruc¬ 
turan lógicamente. 

La minería de datos involucra usar una base de datos para la selección más selectiva de 
clientes. Al asumir que el comportamiento del pasado es un predictor bueno para las com¬ 
pras del futuro, las compañías recopilan datos sobre una persona quien en el pasado hizo 
compras con su tarjeta de crédito, solicitudes de licencia para manejar, llenado de tarjetas de 
garantía, etc. La minería de datos puede ser poderosa, pero podría ser costosa y necesita ser 
coordinada. Además, podría infringir la privacidad del cliente o incluso los derechos civiles 
de una persona. 


PALABRAS Y FRASES CLAVE 

almacenamiento de datos 
asistente 

barra de navegación 
búsqueda en la Web 
consulta 

cuadro de diálogo 
fichas de opciones 

interfaces de formulario (formulario de 
entrada/salida) 

interfaz de formulario basado en la Web 
interfaz de lenguaje de comandos 
interfaz de lenguaje natural 


interfaz de pregunta y respuesta 
interfaz gráfica de usuario (GUI) 
lápiz 
lealtad 

lenguaje de consultas estructurado 
(SQL) 

mapa del sitio 
menú 

menú desplegable 
menú rollover 
menús anidados 
minería de datos 
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motor de búsqueda 
navegación de un solo clic 
navegación intuitiva 
operadores booleanos 
pantalla sensible al tacto 


plantilla 

reconocimiento de voz y síntesis 
retroalimentación 

retroalimentación para los usuarios 
sistema de voz continua 


PREGUNTAS DE REPASO 


1. 

2 . 

3. 

4. 

5. 

6 . 

7. 

8 . 

9. 
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13. 

14. 

15. 

16. 

17. 

18. 

19. 

20 . 
21 . 
22 . 

23. 

24. 

25. 

26. 

27. 
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¿Cuáles son los cinco objetivos para diseñar interfaces de usuario? 

Defina las interfaces de lenguaje natural. ¿Cuál es su desventaja principal? 

Explique lo que significa interfaces de pregunta y respuesta. ¿A qué tipo de usuarios sa¬ 
tisfacen mejor? 

Describa cómo usan los usuarios los menús en pantalla. 

¿Qué es un menú anidado? ¿Cuáles son sus ventajas? 

Defina los formularios de entrada/salida en pantalla. ¿Cuál es su ventaja principal? 
¿Cuáles son las ventajas de los formularios basados en la Web? 

¿Cuáles son las desventajas de las interfaces de formulario basado en la Web? 

Explique qué son las interfaces de lenguaje de comandos. ¿A qué tipos de usuarios sa¬ 
tisfacen mejor? 

Defina las interfaces gráficas de usuario. ¿Cuál es la principal dificultad que presentan 
para los programadores? 

¿Para qué tipo de usuario es particularmente eficaz una GUI? 

¿Cuáles son los tres lineamientos para diseñar diálogo de pantalla adecuado? 

¿Cuáles son los papeles de iconos, gráficos y color en la retroalimentación propor¬ 
cionada? 

Mencione seis formas para lograr la meta de minimizar la intervención del operador al 
diseñar una interfaz de usuario. 

Mencione cinco estándares que pueden ayudar en la evaluación de las interfaces de 
usuario. 

¿Cuáles son las siete situaciones que requieren la retroalimentación para los usuarios? 
¿Cuál es una forma correcta de decir al usuario que la entrada fue aceptada? 

¿Cuándo se informa a un usuario que su entrada no es correcta, qué retroalimentación 
adicional se debe dar al mismo tiempo? 

¿Por qué es inaceptable notificar al usuario que la entrada no es correcta solamente me¬ 
diante la emisión de un sonido? 

¿Cuándo una petición no se completa, qué retroalimentación se debe proporcionar al 
usuario? 

Describa dos tipos de diseño de sitio Web de comercio electrónico para producir re¬ 
troalimentación de los clientes del sitio Web. 

Mencione cuatro formas prácticas que un analista puede mejorar la facilidad de nave¬ 
gación del usuario y la lealtad a un sitio Web de comercio electrónico. 

¿Qué son los vínculos de hipertexto? ¿Dónde se deben usar? 

Mencione en una notación de método abreviado los seis tipos de consulta básicos. 
Mencione seis lineamientos para la búsqueda en la Web. 

¿Cuál es el propósito de la minería de datos? 

¿Qué clase de información se "extrae" de la minería de datos? 

Describa cuatro problemas con la minería de datos. 


PROBLEMAS 

1. Diseñe una interfaz de menús anidados para un sistema de registro y salida de huéspe¬ 
des a un hotel. Use números para seleccionar un artículo del menú. Muestre cómo se 
debe ver cada menú en una pantalla de PC estándar. 

2. Diseñe una interfaz de formulario para el control de inventario para una compañía de 
ventas al por mayor de CDs de música que se podría usar en una pantalla de despliegue 
de PC. 
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3. Diseñe una interfaz de formulario basado en la Web para lograr la misma tarea que en 
el problema 2. 

a. ¿Qué dificultades encontró? Discútalas en un párrafo. 

b. ¿De los dos diseños que hizo, cuál diría que satisface mejor la tarea? ¿Por qué? 
Mencione tres razones para su opción. 

4. Diseñe una interfaz de lenguaje de comandos que un agente de viaje usaría para reser¬ 
var asientos de una aerolínea. 

a. Muestre cómo se vería en una pantalla estándar. 

b. Haga una lista de comandos necesarios para reservar un asiento de la aerolínea y 
apunte el significado de cada comando. 

5. Diseñe una interfaz gráfica de usuario para un escritorio ejecutivo. Use iconos para los 
archiveros, una papelera, un teléfono, etc. Muestre cómo aparecerían en la pantalla de 
la computadora. 

6. Diseñe una pantalla que proporcione retroalimentación apropiada un usuario cuyo co¬ 
mando no se puede ejecutar. 

7. Diseñe una pantalla para un paquete de software de nómina que despliega información 
que le dice al usuario cómo conseguir retroalimentación más detallada. 

8. Diseñe una pantalla que se basa en la Web que muestra una forma aceptable par decir 
a los usuarios que sus entradas fueron aceptadas. 

9. Diseñe un formulario de retroalimentación para clientes que usan un sitio Web de co¬ 
mercio electrónico. 

10. Escriba seis consultas diferentes para el archivo en el problema 1 del capítulo 13. 

11. Escriba seis consultas diferentes para la relación 3NF en el problema 6 del capítulo 13. 

12. Diseñe una búsqueda que encontrará en Web a los competidores potenciales de una 
compañía tal como World's Trend. Suponga que usted es el cliente. 

13. Busque en Web competidores potenciales para World's Trend. (Recuerde que no en¬ 
contrará a World's Trend en Web. Es una compañía ficticia.) Haga una lista de aquéllos 
que ha encontrado. 

14. Diseñe un proyecto para la minería de datos para World's Trend. ¿Qué información se 
necesita? Sugiera algunos proyectos que puede emprender con la minería de datos pa¬ 
ra mejorar los esfuerzos de marketing en World's Trend. 

15. Tomando los datos de su búsqueda para los competidores en el problema 13, haga una 
lista breve de las innovaciones del sitio Web que están usando que podría ser de uso pa¬ 
ra World's Trend en su proyecto de minería de datos. 

16. Prepare un juego de lincamientos éticos o cree una política para ayudar a analistas a 
evaluar los usos apropiados para la minería de datos (también podría tener que definir 
qué usos no son apropiados). En un párrafo, discuta algunas precauciones que deben 
tomarse por el analista para proteger la privacidad del consumidor que podría estar 
enjuego en los proyectos de minería de datos. 


PROYECTOS DE GRUPO 

1. Con los miembros de su grupo, cree un menú desplegable para una agencia de empleo 
que hace coincidir a los candidatos profesionales con las vacantes. Incluya una lista de 
pulsaciones que invocarían las opciones del menú que usan directamente el formato 
de ALT-X. El menú tiene las siguientes opciones: 


Agregar empleado 
Cambiar empleado 
Eliminar empleado 


Agregar patrón 
Cambiar patrón 
Eliminar patrón 


Agregar vacante 
Cambiar vacante 
Eliminar vacante 


Consulta de empleado 
Consulta de posición 
Consulta de patrón 


Coincidir empleado con vacante 

Imprimir el informe vacantes 

Imprimir informe de coincidencias exitosas 
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2. En un párrafo, describa los problemas que su grupo enfrentó al crear este menú. 

3. La característica arrastrar y soltar se usa en GUIs y permite al usuario mover las frases 
alrededor en un paquete de procesamiento de texto. Como un grupo, sugiera cómo se 
puede usar arrastrar y soltar a su máximo potencial en las siguientes aplicaciones: 

a. Software de administración de proyecto (capítulo 3). 

b. Programa de base de datos relacional (capítulo 13). 

c. Diseñador de pantallas o formularios (capítulo 12). 

d. Programa de hoja de cálculo (capítulo 10). 

e. Herramienta CASE para dibujar diagramas de flujo de datos (capítulo 7). 

f. Programa de fax (capítulo 11). 

g. Programa de administración de archivos (capítulo 14). 

h. Administración de información personal (PIM) (capítulo 3). 

i. Ilustración en un paquete de dibujo (capítulo 10). 

j. Herramienta CASE para desarrollar diccionarios de datos (capítulo 8). 

k. Programa para dibujar árbol de decisión (capítulo 9). 

l. Sitio Web para recopilar las opiniones del cliente de los nuevos productos (capí¬ 
tulo 11). 

m. Organizar marcas para los sitios Web. 

Para cada solución que su grupo diseña, dibuje la pantalla y muestre el movimiento 
usando una flecha. 

4. Pida a todos los miembros de su grupo que siliciten una búsqueda basada en sus acti¬ 
vidades de ocio. Si hay cuatro personas en su grupo, sólo se desempeñarán cuatro 
búsquedas. Ahora prosiga y haga todas las búsquedas. Compare sus resultados. ¿La per¬ 
sona que está involucrada con la actividad tiene una ventaja sobre las personas que sa¬ 
ben menos sobre esta? Explique. 
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"Tomemos nuestros prototipos y algunas pantallas, informes y formularios nuevos para 
crear la interfaz de usuario final", le dice Anna a Chip. 

"Es por el tiempo, ¿verdad?", responde Chip. También él está consciente de la impor¬ 
tancia de diseñar una buena interfaz de usuario. 

Después de discutirlo, establecen los siguientes lineamientos para las pantallas de cua¬ 
dros de diálogo: 

1. Las pantallas bien diseñadas deben: 

Comunicar con toda claridad las acciones e intenciones a los usuarios. 

Mostrar a los operadores las opciones disponibles. Por ejemplo: 

MAKE CORRECTIONS OR PRESS ESC TO CANCEL 
ENTER HARDWARE INVENTORY NUMBER 
PRESS ENTER KEY 

PRESS ENTER TO CONFIRM DELETE, ESCTO CANCEL 
Botones OK o Cancel 

Estandarizar el uso de cualquier abreviatura. 

Evitar el uso de códigos, y sustituirlos por los conceptos que los describen. 

Ofrecer pantallas de ayuda para las partes complejas del cuadro de diálogo. 

Incluir sugerencias de ayuda en los iconos de las barras de herramientas. 

2. Se debe proporcionar retroalimentación a los usuarios. Esta retroalimentación incluye: 

Títulos para mostrar la página actual. 

Mensajes para las acciones que se realicen con éxito, como: 

RECORD HAS BEEN ADDED 
RECORD HAS BEEN CHANGED 
Mensajes de error. Por ejemplo: 

INVALID DATE 
CHECKDIGIT IS INVALID 
SOFTWARE IS NOT ON FILE 

Un cuadro de diálogo para los datos inválidos, con un botón OK en una pantalla de 
interfaz gráfica de usuario. 

Mensajes que indiquen el procesamiento, como: 

PLEASE WAIT—REPORT IS BEING PRODUCED 
Un reloj de arena en movimiento en una interfaz gráfica de usuario. 

3. El diseño debe ser consistente, con aspectos como: 

Ubicación del OPERATOR MESSAGE o el FEEDBACK MESSAGE en la parte 
inferior de la pantalla o en la línea de estado. 

Fecha, hora, nombre del sistema y número de referencia de la pantalla en las líneas 
de título. 

Salida similar para todas las pantallas, utilizando, por ejemplo, la misma tecla de función. 
Uso estándar de teclas, como PgDn y PgUp, para desplegar la página siguiente o la 
anterior en una pantalla que contenga numerosas páginas. 

Un método consistente para cancelar una operación, por ejemplo, mediante la tecla 
de escape (Esc). 

Uso estándar de pantallas de color y alta intensidad, por ejemplo, con todos los men¬ 
sajes de error en color rojo. 

Uso estándar de iconos en una pantalla de GUI. 

Menús desplegables estandarizados en una pantalla de GUI. 
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4. El operador debe realizar pocas acciones para utilizar el sistema. Por ejemplo: 

El uso de Y y N para dar respuestas. Utilizar los signos de suma (+) y resta (-] del te¬ 
clado numérico en lugar de Y y N. 

Al cambiar o eliminar registros, sólo debe especificarse la clave del registro. El siste¬ 
ma debe obtener el registro y desplegar la información respectiva. 

Cuando se requieren nombres como entradas de clave, sólo es necesario introducir 
las primeras letras del nombre. El programa debería buscar todos los nombres de 
clave de registro coincidentes y presentarlos al operador para que elija alguno. 

Las pantallas de entrada de datos deben permitir la introducción de códigos. 

Todas las entradas numéricas podrían ignorar los ceros a la izquierda, las comas o un 
punto decimal. 

Al completar un campo, el cursor debe avanzar al siguiente campo de entrada. 

Después de terminar cada opción, la misma pantalla, con áreas de entrada en vacías, 
se debe volver a desplegar hasta que se opcima la tecla Exit. 

Cuando se salga de una opción, se debe desplegar el menú anterior. 

Siempre que sea posible, se deben utilizar cuadros de lista desplegables en pantallas 
de GUI. 

Siempre que sea posible, se deben utilizar casillas de verificación y botones de op¬ 
ción para realizar selecciones. 

Se deben resaltar los botones predeterminados para que el usuario los seleccione con 
la tecla Enter. 

5. Se deben validar los datos que entren al sistema. Los lincamientos son los siguientes: 

Campos específicos se deben verificar de acuerdo con criterios de edición. 

Al detectarse errores, se debe dar a los operadores la opción de corregirlos o de can¬ 
celar la transacción. 

Cuando no se detecten errores en una transacción, se debe presentar la entrada al 
operador para que la confirme visualmente. El operador debe contar con la opor¬ 
tunidad de aceptarla o de hacer correcciones a los datos introducidos. 


Después de examinar las numerosas pantallas e informes (más de 30], Chip y Anna de¬ 
ciden dividir el menú en varias funciones. "¿Cómo dividimos estas diversas funciones en un 
conjunto de menús?", preguntó Chip. 

"Podemos utilizar un diagrama de descomposición para organizar las funciones en una 
jerarquía", contestó Anna. Chip y ella comienzan a trabajar en el diagrama. Las interaccio¬ 
nes de los menús se representarán en una estructura jerárquica, con opciones mostradas co¬ 
mo rectángulos y el menú global representado por el rectángulo de la parte superior. Cada 
menú secundario se mostrará debajo del menú principal, con los programas en pantalla en 
el nivel más bajo. Como se muestra en la figura E14.1, el menú principal tendrá seis op¬ 
ciones principales: Update Software, Update Hardware, Inquiry Modify Codes, Training y 
Report. Cada una de estas opciones se subdivide en menús más pequeños o funciones indi¬ 
viduales. El menú Inquiry se subdivide en dos menús más pequeños. Software Options y 
Hardware Options, así como en opciones para ejecutar el Software Expert Inquiry y el 
Printer Location Inquiry. 

Los rectángulos del diagrama de descomposición de funciones se implementan utili¬ 
zando una serie de listas de menú desplegables, que se muestran en la figura E14.2. Obser¬ 
ve que el menú Inquiry tiene funciones que corresponden a los rectángulos de la figura 
E14.1. Debajo de los ménús se incluye una fila de botones para las funciones comunes. Las 
funciones de los menús se incluyen como un conjunto de botones en el área principal de la 
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pantalla, y es posible hacer clic en estos botones para ejecutar sus programas correspondien¬ 
tes. Se decidió que los programas Add Computer, Add Software Package y Change Compu¬ 
ter se ejecutaran directamente desde el menú principal. Al hacer clic en los demás botones 
se despliegan cuadros de diálogo que contienen opciones para seleccionar programas. La fi¬ 
gura E14.3 muestra el cuadro de diálogo para la opción Reports... Se listan todos los infor¬ 
mes, con botones Print Preview, Print y Cióse Forrn para elegir acciones. 

"Éstos son los lincamientos que considero adecuados para los programas de actualiza¬ 
ción", dice Anna a Chip. "El enfoque principal está en la precisión, con una gran cantidad de 
edición para cada campo de datos. Los programas que sirven para agregar desplegarán una 
página de entrada y permitirán la creación de registros de hardware o software. Después de 
completar todas las entradas, un usuario deberá verificar dos veces los datos y hacer clic en 
el botón Add Software Record. Los datos que ya se encuentren en el sistema se deben im- 
plementar usando listas desplegables. También hay botones para deshacer cambios, pasar a 
diferentes registros, imprimir el registro, guardar los cambios y salir de la página. Se podría 
agregar un registro únicamente si aún no existe su clave principal. 
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"Las pantallas para borrar deben tener una entrada de clave principal sencilla, como 
COURSE DESCRIPTION en la pantalla DELETE SOFTWARE COURSE", continúa Anna. 
"La pantalla DELETE SOFTWARE COURSE utiliza un botón de búsqueda (los binocu¬ 
lares) para localizar el registro deseado. El registro correspondiente se lee y se despliega la 
información. Los usuarios hacen clic en el botón Delete y se les pide que confirmen la eli¬ 
minación. Si el usuario hace clic en Cancel, se cancela la acción de eliminación. ¿Qué te pa¬ 
rece todo esto?", le pregunta a Chip. 

"Hasta el momento, bastante bien", contesta Chip. "¿Tienes algo sobre los cambios en 
pantalla?" 

"Sí. Las pantallas tienen una clave principal para el registro que se introduce y el re¬ 
gistro coincidente que se lee. Se despliega información del registro que permite al opera¬ 
dor sobreescribir los datos con cambios. Todos los cambios se validarán con edición com¬ 
pleta. Cuando se validen todos los campos con cambios, el usuario debe hacer clic en un 
botón para guardar los cambios. ¿Esto es suficientemente claro para el usuario?", pregunta 
Anna. 

"Creo que es bastante bueno", manifiesta Chip. 

Chip se encarga de la parte de consulta del sistema. El enfoque en estos programas es la 
velocidad. Se obtiene una entrada breve del usuario, y se leen los registros correspondientes. 
Se da formato a la investigación para desplegarla y obtener la máxima comunicación. "Me 
he reunido con varios usuarios", le dice a Anna. "Aquí está una lista de los programas de con¬ 
sulta." Está diseñada cada una de las pantallas de consulta, junto con las tablas de la base de 
datos necesarias y los posibles errores que podrían ocurrir. 
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Cuadro de diálogo para el menú de informes del sistema de cómputo. 


"La primera pantalla que diseñé fue HARDWARE INQUIRY", continúa Chip. "Utilicé 
la descripción de la pantalla que habíamos colocado en el depósito de Visible Analyst des¬ 
pués de que creamos los prototipos." El área Notes contiene información sobre la manera en 
que debía operar. Se debe introducir un INVENTORY NUMBER o un INVENTORY 
NUMBER parcial. Se lee el primer registro coincidente (en este caso de un INVEN¬ 
TORY NUMBER parcial), y el usuario puede desplazarse al registro siguiente o al anterior. 

"Elaboré un borrador del diseño y me reuní con Dot para pedirle su opinión acerca del 
diseño", dice Chip. "Después de señalar algunas correcciones sencillas, ella me dijo que se 
debían incluir los detalles del mantenimiento, con una información completa para cada 
computadora." 

La lógica del programa es utilizar el HARDWARE INVENTORY NUMBER como 
campo de entrada del cuadro de diálogo Parameter Valué (el cual se ilustra en la figura 
E14.4), con el número inicial 3. El registro se busca en la base de datos. Si no se localiza, se 
despliega un mensaje. Una vez que se localiza, se leen los registros de tarjetas coincidentes. 
Los registros de tarjetas contienen un código con el tipo de tarjeta, y éste se busca en la 
BOARD CODE TABLE. Se da formato en la pantalla al concepto que describe el código. 
La pantalla resultante se ilustra en la figura E14.5. Observe que hay botones para imprimir 
el registro actual del formulario y para cerrar el formulario. El botón New Inventory Num- 
ber vuelve a desplegar el cuadro de diálogo Parameter Entry, donde el usuario puede elegir 
un nuevo registro. 

"Elegí la consulta SOFTWARE LOCATION para desarrollar la siguiente pantalla", le 
dice Chip a Anna. "Después de una extensa conversación con Cher, redacté los detalles y los 
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Cuadro de diálogo HARDWARE INVENTORY NUMBER, para introducir parámetros. 


documenté en el depósito de Visible Analyst. El campo de entrada es un TITLE de softwa¬ 
re parcial, que se introduce en un cuadro de diálogo Parameter Valué. Se despliega el pri¬ 
mer registro que coincide con el TITLE parcial, y, puesto que existen diferentes sistemas 
operativos y versiones del software, el usuario puede hacer clic en botones para avanzar al 
siguiente (o al anterior) registro. Se despliegan cinco columnas de información: HARDWA¬ 
RE INVENTORY NUMBER, BRAND ÑAME, MODEL, CAMPUS y ROOM. Cher puede 
localizar rápidamente una máquina que contenga el software deseado. Hasta ahora ella pa¬ 
rece estar feliz con esta idea", agrega Chip. 

El programa localiza el registro SOFTWARE MASTER mediante la clave alterna TI¬ 
TLE. Si no se encuentra el registro coincidente, se despliega un mensaje de error. Dado que 
podría haber diversas versiones, tal vez sea necesario hacer clic en el botón Next Record 
hasta que se obtengan el OPERATING SYSTEM y el VERSIÓN NUMBER correctos. 

Una vez que se obtiene el software correcto, se utiliza el archivo relacional para buscar 
el SOFTWARE INVENTORY NUMBER coincidente. Este archivo relacional contiene el 
SOFTWARE INVENTORY NUMBER y el HARDWARE INVENTORY NUMBER coinci¬ 
dente, que se emplea para localizar el registro coincidente en el COMPUTER MASTER. 
Para cada máquina coincidente, la tabla CAMPUS se utiliza para localizar el código CAMPUS 
LOCATION y desplegar el CAMPUS DESCRIPTION coincidente. El área para desplegar 
las máquinas que contienen el software es una región que se puede desplazar, ya que podría 
contener más máquinas de las que cabrían en una sola pantalla. 

"Creo que tenemos un buen comienzo para diseñar nuestras interfaces de usuario", co¬ 
menta Anna. Chip asienta con la cabeza. 
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í FIGURAf El 4¡5| 

Pantalla de consulta HARDWARE INVENTORY NUMBER representada en Microsoft Access. 



EJERCICIOS 

E-l. Use Microsoft Access para ver las opciones de menús del sistema de cómputo. 

E-2. Analice el HARDWARE INQUIRY. Explique el tipo de consulta con la notación va¬ 
lor, entidad y atributo {V, E, A). 

E-3. Explique en un párrafo por qué una pantalla de entrada de datos debe poner énfasis 
en la precisión, en tanto que una pantalla de consulta se enfoca en la velocidad con 
que se despliegan los resultados. 

E-4. Modifique e imprima el diagrama de jerarquía que representa el menú Update 
Hardware. Agregue rectángulos para representar las siguientes opciones de menú: 
CHANGE COMPUTER 
DELETE COMPUTER RECORD 
UPDATE INSTALLED COMPUTER 

E-5. Utilice la característica Functional Decomposition de Visible Analyst para dibujar un 
diagrama de jerarquía que represente las opciones del menú Update Software. Empie¬ 
ce con el rectángulo de la parte superior que representa el menú Update Software. 
ADD SOFTWARE PACKAGE 
CHANGE SOFTWARE RECORD 
DELETE SOFTWARE RECORD 
UPGRADE SOFTWARE PACKAGE 


Los ejercicios precedidos por un icono Web indican que en el sitio Web del libro hay material de valor 
agregado. Los estudiantes pueden descargar una base de datos de Microsoft Access que pueden utilizar 
para completar los ejercicios. 
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E-6. Chip y Anna se percatan de que el menú que se ha diseñado es para los usuarios que 
realizan la instalación y el mantenimiento del hardware y el software de cómputo. Es¬ 
te menú no es apropiado para los miembros del personal y el profesorado, porque 
ellos no tendrán la capacidad para actualizar los registros. Diseñe un menú, en papel 
o software con el cual esté familiarizado, que le proporcione al usuario la capacidad 
de producir consultas e informes. 

E-7. Explique en un párrafo por qué los usuarios tendrían que desplazarse a otra página 
(oprimiendo el botón Next Record) para desplegar el registro correcto para la con¬ 
sulta SOFTWARE LOCATION. 

E-8. Diseñe la pantalla de la consulta SOFTWARE DETAILS. El campo de entrada es 
SOFTWARE INVENTORY NUMBER, y se debe desplegar toda la información del 
software, excepto EXPERT y MACHINES INSTALLED ON. Consulte la entrada 
del depósito para el flujo de datos SOFTWARE DETAILS en Visible Analyst. 

E-9. Al programar salones de clase para los estudiantes, Cher Ware necesita saber qué pa¬ 
quetes de software tiene cada salón. A ella le gustaría introducir el CAMPUS LO¬ 
CATION y el ROOM en una pantalla de consulta. Los campos podrían ser TITLE, 
VERSIÓN, SITE LICENSE y NUMBER OF COPIES. 


Diseñe la consulta SOFTWARE BY ROOM, que se describe como flujo de datos 
en el depósito de Visible Analyst. 

(f^\f E-10. Mike Crowe necesita saber qué tarjetas componentes se encuentran instaladas en 
cada máquina. Utilice Visible Analyst para ver la entrada del flujo de datos para 
COMPONENT BOARD y diseñar la consulta COMPONENT BOARD. El campo 
de entrada es el HARDWARE INVENTORY NUMBER. Los campos de salida son 
BRAND ÑAME, MODEL y una región de desplazamiento para BOARD. La lógica 
consiste en leer el COMPUTER MASTER utilizando el HARDWARE INVEN¬ 
TORY NUMBER. Si no se localiza el registro, despliegue un mensaje de error. Bus¬ 
que los registros BOARD coincidentes. Utilice la notación valor, entidad y atributo 
[V, E, A) para el tipo de consulta. 

Ityf, E-l 1. Ian Perteks recibe con frecuencia solicitudes de ayuda relacionadas con un paque¬ 
te de software en particular. Los miembros del personal y los estudiantes necesi¬ 
tan utilizar opciones avanzadas o transferir datos de y hacia diferentes paquetes, y 
están experimentando problemas. A Ian le gustaría introducir el TITLE y el VER¬ 
SIÓN NUMBER del software. La pantalla resultante debería mostrar el SOFT¬ 
WARE EXPERT ÑAME y su CAMPUS LOCATION y ROOM NUMBER. Diseñe 
la pantalla para la consulta LÓCATE SOFTWARE EXPERT. Describa la lógica y 
los archivos necesarios para producir la consulta. Utilice la notación valor, entidad 
y atributo ¡V, E, A) para esta consulta. Los detalles para esta consulta se incluyen 
en la entrada del depósito para el flujo de datos SOFTWARE EXPERT en Visible 
Analyst. 

íjy E-l 2. En una entrevista de seguimiento con Cher Ware, se determinó que ella necesita sa¬ 
ber qué máquinas están disponibles para instalar algún paquete de software, toman¬ 
do en cuenta los requerimientos de gráficos del paquete. Elabore una consulta que 
le permita a Cher introducir el DISPLAY CODE y, de manera opción, un GRA¬ 
PHICS BOARD y CAMPUS LOCATION del software. Se deben desplegar cuatro 
columnas: 


HARDWARE INVENTORY NUMBER 
CAMPUS LOCATION 
ROOM LOCATION 
GRAPHICS BOARD 
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Consulte el flujo de datos MONITOR REQUIRED de Visible Analyst. Describa 
en un párrafo la lógica necesaria para obtener los resultados. Incluya el tipo de con¬ 
sulta utilizando la notación valor, entidad y atributo [V, E, A). 

-13. Tanto Cher como Ian han manifestado su interés en localizar máquinas de una marca 
específica conectadas a diferentes impresoras. En ocasiones los estudiantes de inge¬ 
niería necesitan un plotter, mientras que en otras situaciones requieren una impreso¬ 
ra láser a color o una portátil. 

Diseñe una consulta que incluya como campos de entrada PRINTER y el 
BRAND ÑAME de la computadora. La salida podría contener dos columnas: CAM¬ 
PUS LOCATION (el nombre completo, no el código] y ROOM LOCATION. Con¬ 
sulte el flujo de datos PRINTER LOCATION en Visible Analyst. 

Describa brevemente la lógica que utilizó para producir la salida. ¿Requerirá esta 
consulta una región de desplazamiento para desplegar toda la información? ¿Por qué 
sí o por qué no? Describa en un párrafo el tipo de consulta utilizando la notación va¬ 
lor, entidad y atributo [V, E, A). 

-14. Ian recibe numerosas peticiones para impartir clases de capacitación. A él le gustaría 
planificar la capacitación y colocar las clases siguientes en la intranet con el fin de 
que el profesorado tenga tiempo suficiente para programar una clase. Diseñe la con¬ 
sulta SOFTWARE TRAINING CLASSES. Puede localizar los detalles en la entrada 
del depósito para el flujo de datos SOFTWARE TRAINING CLASSES en Visible 
Analyst. 
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OBJETIVOS DE APRENDIZAJE 


Una vez que haya dominado el material de éste capítulo, podrá: : ■ « • •••':• 

1. Entender los usos de una codificación efectiva. 

2. Diseñar métodos de captura de datos efectivos y eficientes. 

3. Reconocer cómo asegurar la calidad de los datos a través de la validación. 

4. Mencionar las ventajas de la precisión de la entrada del usuario en los sitios Web 

de comercio electrónico. ’ ; ' : : ;v- /:■.: '' 


Asegurar que.los.-datps ; se.introducen, con precisión éii jel sistema es de suina importanci a, ; ..Esí 
indudable que la calidad dé la entrada de datos determina la calidad de la salida de informa¬ 
ción. El analista de sistemas puede apoyar la entradá de datosiprecisa a trávés dé la consecución."- 
de cuatro objetivos amplios: (1) crear una éódifiéáción significativa patatos datos;:(2] diseñar •; i 
métodos de captura de datos eficientes, [3]' asegurar la. captura de datos>completa y. eficaz, 
y (4) asegurar la calidad de los datos a través'de la validación ■ ¡j ■ * 

. La calidad de ,datos es una medida de qué tan .consistentemente correctos, dentro de 
ciertos límites prefijados, están los datos Los datos, codificados:eficazmente;facilitan la éntrq-; 
da de datos precisa al reducir la cantidad necesaria de datos y,icón ello, el tiempo requerido 
para introducir la infirmación.'. -¡vj -o ;-óy -í’í ó;-., 1 ;-';. ■ ;!y-'• fi'V-yy 

Cuando los datos! se introducen con eficiencia, la entrada de datos sé; ajusta a medidas v 
de desempeño predeterminadas que dan la relación entre el tiempo ertipléádo en la entrada 
y él número de. datos introducidos; Los objetivos de entrada de datos que se, tratan en.este * 
capítulo son: la codificación éféétiva.;': la éntradá y .captura de datos efectiva y éfieiénte \ el • 
aseguramiento de lá calidad de datos a través dé los procedimientos de \ alidación. í. .. 


CODIFICACION EFECTIVA 

Una de lasformas en que los datos pueden ser introducidos de manera mas precisa y efi- . 
■cíente es mediante el empleo inteligente de.varios; códigos. Ef proceso de! poner datos 
ambiguos ó demasiado largos en unos cuantos dígitos o letras que se puedan introducir . 
fácilmente se conoce.como codificación-(que no se debe confundir con, la codificación, : 
de programas |. ■ : , ■;f:;.;. : . .::é’ / ■; ■ i 1 -; ’ ; ; . -. í ó ..j:! 

La-codificación ayuda a que el analista de sistemas alcance el objetivo de eficiencia; de¬ 
bido a quedos datos codificados requieren menos tiémpo'para su captura \ reducen la canti¬ 
dad de elementos capturados! La, codificación también puede contribuir al ordenamiento • 
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adecuado de los datos en un punto posterior del proceso de transformación de datos. 
Asimismo, los datos codificados pueden ahorrar un valioso espacio de memoria y de alma¬ 
cenamiento. En síntesis, la codificación es una forma fluida y concisa de capturar datos. 
Además de proporcionar precisión y eficiencia, los códigos deben tener un propósito. Los 
tipos específicos de códigos nos permiten tratar los datos de una forma particular. Los pro¬ 
pósitos para codificar incluyen lo siguiente: 

1. Llevar registro de algo. 

2. Clasificar la información. 

3. Ocultar la información. 

4. Revelar la información. 

5. Solicitar la acción apropiada. 

Cada uno de estos propósitos para codificar se discute en las siguientes secciones, junto con 
algunos ejemplos de códigos. 

DAR SEGUIMIENTO A ALGO 

A veces simplemente necesitamos identificar una persona, lugar o cosa para darle segui¬ 
miento. Por ejemplo, un establecimiento que fabrica muebles tapizados a la medida necesi¬ 
ta asignar un número de trabajo a un proyecto. El vendedor requiere saber el nombre y la 
dirección del cliente, pero el gerente del taller o los trabajadores que ensamblan los muebles 
no necesitan saber quién es el cliente. Por consiguiente, se asigna un número arbitrario al 
trabajo. El número puede ser aleatorio o secuencial, tal como se describe en la siguiente 
subsección. 

Códigos de secuencia simple El código de secuencia simple es un número que se asigna a 
algo si necesita ser numerado. Por lo tanto no tiene ninguna relación con los datos mismos. 
La figura 15.1 muestra cómo se asigna un número de pedido a los pedidos de un fabricante 
de muebles. Con este número de fácil referencia, la compañía puede dar seguimiento al pe¬ 
dido en proceso. Es más eficiente teclear el trabajo "5676" en lugar de "esa mecedora café y 
negro con asiento de cuero para Arthur Hook, Jr.". 

El uso de un código de secuencia en lugar de un número aleatorio tiene algunas venta¬ 
jas. Primero, elimina la posibilidad de asignar el mismo número. Segundo, da una idea apro¬ 
ximada a los usuarios de cuándo se recibió el pedido. 

Los códigos de secuencia se deben usar cuando el orden del procesamiento requiere co¬ 
nocimiento de la secuencia en la que los conceptos entran al sistema o el orden en que se 
desarrollan los eventos. Un ejemplo se encuentra en el caso de un banco que lanza una pro¬ 
moción especial para la cual es importante saber cuándo solicita una persona un préstamo 
bancario especial de bajo interés, porque (si todas las demás cosas son iguales] los préstamos 
hipotecarios especiales se concederán en el orden en el que lleguen las solicitudes. En este 
caso es importante asignar un código de secuencia correcta a cada solicitante. 

Códigos de derivación alfabética En algunas ocasiones no es conveniente usar códigos de 
secuencia. El caso más obvio es cuando no se desea que alguien que lea el código se imagi¬ 
ne la cantidad de números que se han asignado. Otra situación en que los códigos de se¬ 
cuencia podrían no ser útiles es cuando se requiere un código más complejo para evitar un 
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secuencia simple para Indicar =• 

# Pedido 

Producto 

Cliente 

5676 ' ¡i" 

Mecedora de piel 

Zambrano José 

(la secuencia en que se ingresan 

5677 

Silla de comedor tapizada 

López Juan 

los pedidos en una tienda de 

5678 ■,■■■■ 

Sofá tapizado 

Arteaga María 

muebles hechos a la medida. 

5679 -. 

Mecedora para niño . 

Pérez Antonio 
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Explicación de código 


68506KN D7533TVG' 


99999XXX9999XXX 
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7-Cuatro cigitos ce la- calle 
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Cinco primeros:números del codigo postal 
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error costoso. Un posible error sería sumar un pago a la cuenta 223 cuando lo que se preten¬ 
de es sumarlo a la cuenta 224, debido a que tecleó un dígito incorrecto. 

El código de derivación alfabética es un método que se usa comúnmente para identifi¬ 
car un número de cuenta. El ejemplo de la figura 15.2 proviene de una etiqueta de correo 
para una revista. El código se convierte en el número de cuenta. Los primeros cinco dígitos 
conforman los primeros cinco dígitos del código postal del suscriptor, los siguientes tres 
son las primeras tres consonantes del nombre del suscriptor, los siguientes cuatro números son 
de la calle y los últimos tres constituyen el código para la revista. El propósito principal de 
este código es identificar una cuenta. 

Un propósito secundario es imprimir etiquetas de correo. Al diseñar este código, el códi¬ 
go postal es la primera parte del número de cuenta. Los registros del suscriptor normalmen¬ 
te se actualizan una sola vez al año, pero el propósito principal de los registros es imprimir 
etiquetas de correo una vez al mes o una vez a la semana. Al colocar el código postal como 
la primera parte de un campo de clave principal significa que los registros no tienen que or¬ 
denarse por el código postal para el correo masivo, debido a que los registros en un archivo 
ya se almacenan en secuencia de clave principal. Observe que la fecha de expiración de la 
suscripción no es parte del número de cuenta, debido a que ese número puede cambiar con 
mayor frecuencia que los demás datos. 

Una desventaja de un código de derivación alfabética se presenta cuando la parte al¬ 
fabética es pequeña (por ejemplo, el nombre Po) o cuando el nombre contiene menos 
consonantes que las requeridas por el código. El nombre Roe tiene una sola consonante y 
tendría que ser derivado como RXX o mediante algún otro esquema. Otra desventaja es 
que algunos de los datos podrían cambiar. Cambiar una dirección o un nombre cambiaría 
la clave principal para el archivo. 

CLASIFICACIÓN DE LA INFORMACIÓN 

La clasificación brinda la capacidad de distinguir entre clases de conceptos. Las clasificaciones 
son necesarias para muchos objetivos, tal como reflejar qué partes de un plan de seguro 
médico tiene un empleado o mostrar cuál estudiante ha cumplido con los requisitos básicos 
de sus cursos. 

Para ser útiles, las clases deben ser mutuamente excluyentes. Por ejemplo, si un estudian¬ 
te está en clase F, que significa estudiante de primer año, y ha terminado de 0 a 36 horas de 
créditos, no debe ser también clasificable como estudiante de segundo año (S). Las clases 
se traslaparían si se definiera que F pudiera ser de 0 a 36 horas de créditos mientras que S 
fuera de 32 a 64 horas de créditos, etc. Los datos no son claros ni fácilmente interpretables 
cuando la codificación de las clases no es mutuamente excluyente. 

Códigos de clasificación Los códigos de clasificación se usan para distinguir un grupo de 
datos que tienen características especiales de otro. Los códigos de clasificación pueden con¬ 
sistir de una sola letra o número. Son una forma de método abreviado para describir una 
persona, lugar, cosa o evento. 

Los códigos de clasificación se listan en manuales o se distribuyen para que los usuarios 
puedan localizarlos fácilmente. Muchas veces, los usuarios llegan a familiarizarse tanto con 
los códigos usados con más frecuencia que los memorizan. Un usuario clasifica un elemento 
y luego teclea su código directamente en la terminal de un sistema en línea o en un docu¬ 
mento fuente de un sistema por lotes. 
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Agrupación áe ios eiemenxos 
deducibles de impuestos 
mediante el uso de un código 
de clasificación de una letra. 


Código Elemento deducible de impuestos 

•■•i:;Intereses 
M Medie ñas : . 

A Automóviles 

C Contribuciones 

D Donativos 

S Suministros . 


Un ejemplo de codificación de clasificación es la forma en que podría agrupar los ele¬ 
mentos deducibles de impuesto con el propósito de completar sus impuestos sobre la ren¬ 
ta. La figura 15.3 muestra cómo se desarrollan los códigos para los elementos tal como los 
intereses, las medicinas, las contribuciones, etc. El sistema de codificación es simple: tome la 
primera letra de cada una de las categorías; las contribuciones son C, los pagos de intereses 
son I y los suministros son S. 

Todo va bien hasta que encontramos otras categorías (tal como computadoras, pagos de 
impuestos y seguros) que empiezan con las mismas letras que usamos anteriormente. La 
figura 15.4 demuestra qué sucede en este caso. La codificación se expandió para que pudié¬ 
ramos usar P para "comPutadora", G para "seGuro" y T para "impuesTos". Obviamente, esta 
situación está lejos de ser perfecta. Una forma de evitar este tipo de confusión es permitir 
códigos de más de una letra; esos códigos los explicaremos más adelante en este capítulo 
bajo el subtítulo de códigos mnemónicos. Los menús desplegables en un sistema de GUI a 
menudo usan códigos de clasificación como método abreviado para ejecutar características 
del menú, tal como Alt-A para el menú Archivo. 

Códigos de secuencia en bloques Anteriormente tratamos los códigos de secuencia. 
El código de secuencia en bloques es una extensión del código de secuencia. La figura 15.5 
muestra cómo un negocio asigna números al software de cómputo. Las principales categorías 
de software son paquetes de navegadores, paquetes de base de datos, paquetes de proce¬ 
sadores de texto y paquetes de presentaciones. A éstos se les asignaron números secuenciales 
en los siguientes "bloques" o rangos: navegador, 100-199; base de datos, 200-299, etc. La 
ventaja del código de secuencia en bloques es que los datos se agrupan de acuerdo con 
características comunes, pero aún toma ventaja de la simplicidad de asignar el siguiente 
número disponible (dentro del bloque, por supuesto] al siguiente elemento que necesita 
identificación. 
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Nombre del paquete de software 

Tipo 
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• Microsoft Word;; T j 
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WordPerfect t _ , .. 
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■Astoqnd '. T 

Presentaciones 

í 401 

í -.-.: r-.: 

■ Micrografx Designer 


: 402 

PowerPoint . ' . . r 




'J, .. ‘ . a... 

en ufuques para agrupar ¡os 
paquetes de software similares. 


CÓMO OCULTAR LA INFORMACIÓN 

Los códigos se podrían usar para ocultar o disimular la.información que no queremos que los 
demás conozcan. Hay muchas razones por las que un negocio necesitaría hacer esto. Por 
ejemplo, tal vez una corporación no desee que trabajadores de captura de datos tengan 
acceso a la información de un archivo de personal. Una tienda podría requerir que sus 
vendedores conozcan el precio de mayoreo para que sepan qué tan bajo pueden negociar 
un precio, pero lo pueden codificar en las etiquetas de precios para evitar que los clientes lo 
averigüen. Un restaurante podría desear capturar información acerca del servicio sin permitir 
que el cliente sepa el nombre del mesero. El ocultamiento de la información y la seguridad 
se han vuelto muy importantes en los últimos años. Las corporaciones han empezado a per¬ 
mitir a vendedores y clientes acceder a sus bases de datos directamente y el manejo de las 
transacciones de negocios por Internet ha obligado al desarrollo de esquemas de encriptación 
sólidos. La siguiente subsección es un ejemplo de ocultamiento de información mediante 
códigos. 

Códigos de cifrado Tal vez el método de codificación más simple es la sustitución directa 
de una letra por otra, un número por otro o una letra por un número. Un tipo popular de 
acertijo, llamado criptograma, es un ejemplo de sustitución de letras. La figura 15.6 es un 
ejemplo de un código de cifrado tomado de un almacén de la ciudad de Buffalo, Nueva 
York, que codifica todos los descuentos con las palabras BLEACH MIND. Realmente nadie 
recuerda por qué se escogieron esas palabras, pero todos los empleados las conocen de 
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memoria y por eso el código de cifrado tuvo éxito. Observe en esta figura que un artículo 
con un precio de menudeo de $25.00 tendría un descuento de BIMC o $18.75 cuando se 
decodifica letra por letra. 

CÓMO REVELAR LA INFORMACIÓN 

A veces es deseable revelar la información mediante un código. En una tienda de ropa, la in¬ 
formación acerca del departamento, producto, color y talla se imprime junto con el precio 
en la etiqueta de cada artículo. Esto ayuda a los vendedores y almacenistas a localizar dónde 
se encuentra la mercancía. 

Otra razón para revelar información mediante códigos es hacer más significativa la en¬ 
trada de datos. Un número de parte, nombre o descripción familiar favorece una entrada de 
datos más precisa. Los ejemplos de códigos de la siguiente subsección explican cómo se 
pueden realizar esos conceptos. 

Códigos de subconjuntos de dígitos significativos Cuando es posible describir un produc¬ 
to por medio de su pertenencia a muchos subgrupos, podemos usar un código de subcon¬ 
junto de dígitos significativos que nos ayude a describirlo. El ejemplo de la figura 15.7 de la 
etiqueta de precio de la tienda de ropa, es un ejemplo de un código de subconjunto de dígitos 
significativos. 

Para el observador casual o el cliente, la descripción del artículo parece ser un número lar¬ 
go. Sin embargo, para uno de los vendedores el número está compuesto de unos cuantos nú¬ 
meros más pequeños, cada uno de los cuales tiene su propio significado. Los primeros tres 
dígitos representan el departamento, los siguientes tres el producto, los siguientes dos el color 
y los últimos dos la talla. 
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Los códigos de subconjunto de dígitos significativos podrían consistir en informa¬ 
ción que realmente describe el producto (por ejemplo, el número 10 significa talla 10] o 
números que se asignan arbitrariamente [por ejemplo, 202 se asigna al departamento de 
maternidad]. En este caso, la ventaja de usar un código de subconjunto de dígitos signifi¬ 
cativos consiste en que permite localizar los artículos que pertenecen a determinado 
grupo o clase. Por ejemplo, si el gerente de la tienda decidiera rebajar toda la mercancía 
invernal para una próxima venta, el vendedor podría localizar todos los artículos que 
pertenecen a los departamentos 310 a 449, el bloque de códigos utilizado para designar 
"invierno" en general. 

Otra ventaja de usar códigos de subconjunto de dígitos significativos es que se po¬ 
drían realizar consultas en una parte del código. Al usar el ejemplo ilustrado en la figura 
15.7, un vendedor podría buscar otros artículos rojos que coincidieran, otros artículos en 
talla 10, otros artículos de maternidad o vestidos similares con el mismo estilo. Este códi¬ 
go también es muy útil para comercializar un producto. Las empresas que venden a través 
de Internet a menudo recomiendan productos que piensan que podrían gustarle a un 
cliente. Por ejemplo, si un cliente comprara un cierto tipo de música, un sitio Web podría 
recomendar otra música del mismo género. Cuando un cliente compra un cierto tipo de 
libro, un sitio Web podría recomendar otros títulos que tienen el mismo autor o conteni¬ 
do similar o estilo. 

Códigos mnemónicos Un mnemónico es una ayuda para la memoria. Cualquier código 
que ayude a la persona que captura los datos a recordar la forma de teclear la fecha o a que 
el usuario recuerde cómo usar la información se puede considerar un mnemónico. Al usar 
una combinación de letras y símbolos se logra una forma clara para codificar un producto 
de tal forma que el código sea visto y comprendido fácilmente. 

Como se muestra en la figura 15.8, los códigos del hospital de la ciudad usados anterior¬ 
mente por el Buffalo Regional Blood Center eran mnemónicos. Los códigos simples fueron 
inventados precisamente porque los administradores del banco de sangre y los analistas de sis¬ 
temas quisieron asegurar que los códigos del hospital fueran fáciles de memorizar y de recor¬ 
dar. Los códigos mnemónicos para los hospitales ayudan a disminuir la posibilidad de enviar 
sangre al hospital incorrecto. 


UNICODE 

Los códigos nos permiten revelar caracteres que normalmente no podemos capturar o 
ver. Los teclados tradicionales aceptan conjuntos de caracteres que son conocidos por las 
personas que usan los caracteres alfabéticos occidentales [denominados como caracteres 
latinos], pero muchos lenguajes, tales como el griego, el japonés, el chino o el hebreo, no 
usan el alfabeto occidental. Estos lenguajes podrían usar letras griegas o glifos o símbolos 
que representan sílabas o palabras completas. La Organización Internacional de Estánda¬ 
res [ISO] ha definido el conjunto de caracteres Unicode, el cual incluye todos los símbo¬ 
los comunes del lenguaje y tiene espacio para 65,535 caracteres. Usted puede desplegar 
páginas Web escritas en otros alfabetos descargando un editor de método de entrada de 
Microsoft. 


Código Hospitales de la ciudad 

; . BGH . Buffalo General. Hospital 

ROS Roswell Park Memorial Institute 

'■■■' KEN .. . «c'ificre Mefcy . • . 

DEA . Deaconess Hospital UfAj 

SIS S ste's ol Oarty ' ' : . "p ■i 

Sil- . \ Saint Francis Hospital ;■ L/;j 

SU • 'SáintJoseph's Hospital^ 

.' OLV . : Our Lady ofVictory Hospital' 
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Los símbolos de glifos se representan usando una notación "&#xnnnn;", en la cual nnnn 
representa una letra específica o símbolo y x quiere decir que se usa una notación hexade- 
cimal, o numeración base 16, para representar los caracteres Unicode. Por ejemplo, &#30B3 
representa el símbolo ko del Katakana japonés. El código usado para la palabra japonesa 
equivalente a hola, konichiwa, es &#x3053;&#x306B;&#x3061;&#x308F. En japonés, la 
palabra parece como: 

I K t, h 

ko ni chi wa 

hola 

El conjunto completo de caracteres Unicode se agrupa según su lenguaje y se puede 
encontrar en www.unicode.org. 

SOLICITUD DE LA ACCIÓN ADECUADA 

Los códigos son frecuentemente necesarios para dar instrucciones a las computadoras o 
al tomador de decisiones sobre la acción a tomar. A esos códigos se les menciona general¬ 
mente como códigos de función y por lo general toman la forma de código de secuencia 
o mnemónico. 

Códigos de función Las funciones que el analista o programador desean que la computado¬ 
ra desempeñe con los datos son capturadas en códigos de función. Las indicaciones completas 
sobre las actividades a ser realizadas son reemplazadas mediante el uso de un código numé¬ 
rico o alfanumérico corto. 

La figura 15.9 muestra ejemplos de un código de función para actualizar el inventario. 
Suponga que usted está a cargo de un departamento de productos lácteos; en caso de que 
un yogurt se echara a perder, utilizaría el código 3 para indicar este evento. Por supuesto, los 
datos requeridos para la entrada varían dependiendo de qué función se necesita. Por ejem¬ 
plo, para actualizar un registro sólo se requeriría la clave del registro y el código de función, 
mientras que para agregar un nuevo registro se requerirían todos los elementos de datos a 
ser capturados, incluyendo el código de función. 

LINEAMIENTOS GENERALES PARA LA CODIFICACIÓN 

En las secciones anteriores examinamos las razones para usar diferentes tipos de códigos 
para capturar y almacenar datos. A continuación, examinaremos unas cuantas reglas heu¬ 
rísticas para establecer un sistema de codificación. En la figura 15.10 se resaltan estas 
reglas. 

Sea conciso Los códigos deben ser concisos. Los códigos excesivamente largos significan 
más tecleos y, por consecuencia, más errores. Los códigos largos también significan que el 
almacenamiento de información en una base de datos requerirá más memoria. 

Los códigos cortos son fáciles de recordar y de capturar en comparación con los códigos 
largos. Si los códigos deben ser largos, se deben dividir en subcódigos. Por ejemplo, 
5678923453127 se podría dividir con guiones de la siguiente forma: 5678-923-453-127. 
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"No puedo creerlo. Estuve buscando esta gorra durante 45 minutos"; se 
queja Davey mientras ondea una gorra de piel dé mapáche por la cola. Davey 
es uno de los nuevos almacenistas de Grockett's, una empresa de ventas 
por catálogo: "La lista del catálogo la define como una 'Pma h5-9c/cP. Lo 
bueno es que me dijiste que 'Pma' significa piel de mapache. Por supuesto, 
en seguida pensé en las gorras y vine a buscar aquí. La encontré en este 
contenedor etiquetado como GORRA/NIÑOS. ¿No sería más sencillo que el 
catálogo coincidiera con los contenedores? Para mí, esta factura dice: 'Plu¬ 
mas, tamaño 5-9, con colores 1 . Pasé unbuen rato en el área de papelería." 
., Daniel, compañero de Davey, apenas lo escucha mientras saca apresu¬ 
radamente los artículos de algunos contenedores para surtir otro pedido. 
"Ya te acostumbrarás. Lo han tenido que hacer de esta manera para que 
las computadoras entiendan la factura más tarde. La mayoría de las 
veces, busco el número de página del catálogo en la factura, a continua¬ 
ción la busco en el libro y hago una especie de traducción... á menos que 
la recuerde porque ya la haya buscado antes", explica Daniel. f 

Davey Insiste: "Pero las computadoras son Inteligentes, y nosotros 
tenemos que surtir muchos pedidos. Deberíamos decirle a los encarga¬ 
dos de la facturación los nombres que tenemos en los contenedores". 

Daniel contesta con Ironía: "Sí, cómo no. Semueren por saber lo que 
pensamos". Luego agrega con mástranqullldad: "Es decir, así lo hacíamos, 
pero cuando llegaron las nuevas computadoras'y tuvieron que recibir pedi¬ 


dos por teléfono las 24 horas, todo cambió. Decían que los operadores 
tenían que saber más acerca de lo que vendían, así que cambiaron 
los códigos para que fueran más descriptivos". 

Davey, sorprendido por lo que Daniel le había confiado, pregunta: 
"¿Guales la descripción de lo que yo estaba buscando hace un momento?" 

Después de observar el código de la factura de la gorra, Daniel con¬ 
testa:; "Lo que estabas buscando es 'Pma h5-9c/cl'. Después de buscarlo 
rápidamente en su computadora, el operador puede hacer la siguiente 
descripción al cliente: 'Es una gorra de piel de mapache (Pma) para niño 
(h de hombre), para edades de 5-9, con una verdadera cola de mapache 
.. (c/cl)'. Esto nos dificulta saber de qué artículo se trata, pero ya conoces a 
: Crockett's: Ellos tienen que vender". 

¿Qué tan Importante es que los contenedores del almacén se codifi¬ 
quen de esta manera tan Inconsistente? Dé su respuesta en un parra-.' 
. fo. ¿Qué prübjemásse derivan de que un código tenga una apariencia 
nemónica pero nunca sé proporcione a los empleados una "clave" 
apropiada para que lo descifren? Explique su respuesta en dos párra¬ 
fos. ¿Qué cambios haría usted a la manera en que Crockett's codifica 
sus facturas y su almacén? Ponga por escrito estos cambios, Identifique 
el tipo de código que usted utilizaría y dé un ejemplo donde emplee el 
código de alguno de los productos que podría vender Crockett's. Recuerde 
también descifrarlo. 


Éste es un enfoque más manejable y aprovecha la forma en que se sabe que la gente proce¬ 
sa información en grupos cortos. Por alguna razón, a veces los códigos se hacen más largos 
de lo necesario. Los números de tarjeta de crédito a menudo son largos para impedir que las 
personas adivinen un número de tarjeta de crédito. Visa y MasterCard usan números de 16 
dígitos, con capacidad para abarcar a nueve billones de clientes. Debido a que los números 
no se asignan secuencialmente, las oportunidades de adivinar un número de tarjeta de cré¬ 
dito son muy pocas. 


Conserve estables los códigos La estabiüdad significa que el código de identificación para 
un cliente no debe cambiar cada vez que se reciben nuevos datos. Anteriormente presenta¬ 
mos un código de derivación alfabética para una lista de suscripción de una revista. La fecha 
de expiración no fue parte del código de identificación del suscriptor, debido a que es muy 
probable que cambie. 

No cambie las abreviaturas del código en un sistema mnemónico. Una vez que ha 
escogido las abreviaturas del código no trate de modificarlas, debido a que esto hace ex¬ 
tremadamente difícil la adaptación del personal de entrada de datos. 


Al establecer un sistema de 
codificación, el analista debe: 


Procurar que los códigos sean concisos 
, Conservar estables.los códigos , 

Asegurar que los códigos sean únicos 

Procurar qué los: códigos so puedan ordenar 
: Evitar códigos confusos " 

Mantener la uniformidad de los códigos 
Permitir la modificación de tosí códigos 
Hacor'códigos significativos L , 


H?y ocho.ír ui-rtíartts. Surales 
p is0*1?jitv» ..¿¿lOrr de ■ 
codificación. 
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Planee con anticipación con el 
fin de hacer algo con los datos 
que se han capturado. En este 
ejemplo, la persona que crea 
los códigos no entiende que los 
datos se deberían ordenar. 


Ordenamiento Ordenamiento Ordenamiento incorrecto Ordenamiento 

incorrecto usando incorrecto usando (problema en el año 2000) correcto usando 


MMM-DD-AAAA MM-DD-AAAA AA-MM-DD AAAA-MM-DD 


Dlc-25-1998 06-04-1998 . 00-06-11 ■ 1997-06-12 

Dic 31-1997 06-11-2000 97 06-12 1997 12-31 

; Jul-04-1999 06-12-1997 ' 97-12-31 1998-06-04; i, 

Jun-04-1998 07-04-1999 98-06-04 1998-10-24, 

Jun-Í 1-2000 .- 10-24-1998 •• ■ .98-10-24 1998-12-25 

Jun-12-1997 12-25-1998 .98-12-25'- r ■ 1999-07-04 

Oct-24-1998 12-31-1997 99-07-04 , 2000-06-11:;: 


Asegúrese de que los códigos sean únicos Para que los códigos funcionen deben ser únicos. 
Tome nota de todos los códigos usados en el sistema para asegurarse de que no está asignando 
el mismo número o nombre de código a los mismos elementos. Los números y nombres 
de código son una parte esencial de las entradas de los diccionarios de datos, los cuales se 
analizaron en el capítulo 8. 

Procure que los códigos se puedan ordenar Si va a manejar los datos en forma útil, los có¬ 
digos deben ser ordenables. Por ejemplo, si va a desempeñar una búsqueda de texto en los 
meses del año en orden ascendente, los meses "J" estarían fuera de orden (julio y luego ju¬ 
nio). Los diccionarios se ordenan de esta forma, una letra a la vez de izquierda a derecha. 
De tal manera, si ordenó MMMDDAAAA donde MMM representa la abreviatura para el 
mes, DD para el día y AAAA para el año, el resultado podría ser un error. 

La figura 15.11 muestra lo que pasaría si una búsqueda de texto se desempeñara en 
formas diferentes por fecha. La tercera columna muestra un problema que fue parte de 
la crisis del año 2000 (Y2K), que causó alguna alarma e incluso apareció en la revista 
Time. 

Una de las lecciones aprendidas es asegurarse de que puede hacer lo que piensa hacer 
con los códigos que elabore. Los códigos numéricos son mucho más fáciles de ordenar que 
los alfanuméricos; por consiguiente, considere la conversión a numéricos siempre que sea 
posible. 

Evite los códigos confusos Trate de evitar el uso de caracteres de codificación que parez¬ 
can o se oigan iguales. Los caracteres O (la letra O) y 0 (el número cero) se confunden con 
facilidad, al igual que ocurre con la letra I y el número 1 y también con la letra Z y el núme¬ 
ro 2. Por lo tanto, códigos tales como B1C y 280Z son inadecuados. 

Como se muestra en la figura 15.12, el código postal canadiense es un ejemplo de un 
código potencialmente confuso. El formato del código es X9X 9X9, donde X representa 
una letra y 9 un número. Una ventaja de usar letras en el código es permitir más datos en un 
código de seis dígitos (hay 26 letras, pero sólo 10 números). Debido a que los canadienses 
utilizan con mucha frecuencia el código, para ellos el código es perfectamente lógico. Sin 
embargo, para los extranjeros que envían correo a Canadá podría ser difícil adivinar si el pe¬ 
núltimo símbolo es una Z o un 2. 




Al combinar caracteres similares 
en los códigos pueden resultar 


errores. 


Formato de código para el código postal 
canadiense X9X 9X9 

Código escrito a mano Código real Ciudad, provincia Problema 

L6S 4M4 L8S 4M4 L-. Hamilton,.Ontario • . La S parace 5 

T3A ZE5 T3A 2E5 Calgary. Alberta, El. 2 parece Z 

' '.i*''iP’’i: T:T'b-:? : L : j'" : ÍPP" yí.LL irSiLv El. 5 parece S • ’ . 

LOS 1J0 LOS 1J0 Niágara. Ontario El cero y la 0 se parecen 

Ontario La S parece 5 

El 1 parece 1 
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Mantenga la uniformidad de los códigos Los códigos necesitan seguir formas que se per¬ 
ciban con facilidad la mayor parte del tiempo. Los códigos usados en conjunto, tal como 
BUF-234 y KU-3456, son pobres porque el primero contiene tres letras y tres números, 
mientras que el segundo sólo tiene dos letras seguidas por cuatro números. 

Cuando se le pida agregar fechas, intente evitar usar los códigos MMDDAAAA en una 
aplicación, AAAADDMM en una segunda y MMDDAA en una tercera. Es importante 
mantener los códigos uniformes entre sí y entre los programas. 

En el pasado, la uniformidad significó que todos los códigos mantenían la misma longi¬ 
tud. Con la introducción de sistemas en línea, la longitud no es tan importante como una 
vez lo fue. Con los sistemas en línea, la tecla Enter se presiona después que el operador se 
asegura de que la entrada de datos es correcta, así que no representa mucha diferencia si el 
código tiene una longitud de tres o cuatro caracteres. 

Permita la modificación de los códigos La adaptabilidad es característica importante.de 
un buen código. El analista debe tener presente que el sistema evolucionará con el paso 
del tiempo y el sistema de codificación debe tener la flexibilidad de aceptar el cambio. El 
número de clientes debe crecer, los clientes cambiarán de nombre y los proveedores mo¬ 
dificarán la forma en que numeran sus productos. El analista debe tener la capacidad de 
prever los cambios predecibles y anticipar una amplia gama de necesidades futuras al diseñar 
códigos. 

Haga códigos significativos A menos que el analista quiera esconder la información in¬ 
tencionalmente, los códigos deben ser significativos. Los códigos eficaces no sólo contienen 
información, sino que también tienen sentido para las personas que los usan. Los códigos 
significativos son fáciles de entender, trabajar y recordar. El trabajo de entrada de datos se 
vuelve más interesante al trabajar con códigos significativos en lugar de sólo capturar una 
serie de números sin sentido. 

Uso de códigos Los códigos se usan de varias formas. En los programas de validación, los 
datos de entrada se verifican contra una lista de códigos para asegurar que sólo se han captu¬ 
rado códigos válidos. En los programas de informe y consulta, un código almacenado en un 
archivo se transforma en el significado del código. Los informes y pantallas no deben mostrar 
o imprimir el código real. Si lo hicieron, el usuario tendría que memorizar los significados 
del código o buscarlos en un manual. Los códigos se usan en los programas de GUI para 
crear listas desplegables. 


CAPTURA DE DATOS EFECTIVA Y EFICIENTE 

Para asegurar la calidad de los datos que se capturan en el sistema, es importante ser eficaz 
en su captura. La captura de datos cada vez ha recibido más atención por ser el punto en 
el procesamiento de información en el cual se puede ganar mayor productividad. Desde 
los años setenta se ha tenido gran avance en la manera de capturar datos, conforme nos he¬ 
mos alejado de sistemas de múltiples pasos, lentos y propensos a errores, tales como tarjetas 
perforadas, para dar paso a sistemas sofisticados que incluyen cosas tales como reconoci¬ 
miento óptico de caracteres (OCR], códigos de barras, terminales de punto de venta y es- 
caneo de caracteres especiales en revistas y catálogos hasta llegar a un sitio Web. 

QUE SE DEBE CAPTURAR 

•La decisión de qué capturar precede a la interacción del usuario con el sistema. De hecho, 
es vital para hacer la interfaz útil, recuerde que el dicho "basura entra, basura sale" aún es 
verdad. 

Las decisiones sobre qué datos capturar para la entrada del sistema se toman entre 
analistas de sistemas y usuarios de sistemas. Mucho de lo que se capturará es específico pa¬ 
ra un negocio particular. Capturar, introducir, almacenar y recuperar datos son actividades 
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RESERVACION INICIAL 

La recepcionlsta captura nombre: 
j dirección, teléfono e información 
• de |a tarjeta de crédito, además de| 
: los días de estancia en el hotel. 


REGISTRO 

La recepciomsta sólo captura 
las primeras cinco letras del $ 
aoellido (si fuera necesario 
se capturaría otra información); 






Dirección, teléfono, reservación e 
Información de tarjeta de crédito que 
anteriormente fue almacenada, así 
como también la fecha y hora actuales 


Registrar automáticamente la ' 
fecha y hora en un sistema de 
reservaciones de un hotel elimina 
la entrada de datos innecesarias. 


: Información requerida 5 

para el registra, salida l 

y facturación « 


El software se puede escribir para pedir al usuario que capture la fecha de hoy o para 
que la tome del reloj interno de la computadora. Una vez capturado, el sistema procede a 
usar esa fecha en todas las transacciones procesadas en esa sesión de entrada de datos. 

En la figura 15.13 se muestra parte de una pantalla de un sistema para reservaciones de 
un hotel y registros de huéspedes. Observe que cuando se hace una reservación inicialmen¬ 
te, se capturan el nombre y el número de la tarjeta de crédito del huésped. Cuando el 
huésped se registra, la recepcionista presenta en pantalla el registro sin tener que volver a 
capturar totalmente el nombre o el número. El sistema también registra automáticamente 
la fecha y la hora, ahorrando entrada de datos extensa. 

Un primer ejemplo de reusar los datos capturados una vez es el de las computadoras 
en línea del centro bibliotecario (OCLC) utilizado por miles de bibliotecas en Estados 
Unidos. OCLC se construyó con la idea de que cada artículo comprado por una bibliote¬ 
ca sólo debe ser catalogado una vez durante todo el tiempo. Cuando se introduce un artícu¬ 
lo, la información de catalogación entra en la gran base de datos de OCLC y se comparte 
con todas las bibliotecas. En este caso, la implementación del simple concepto de capturar 
datos una sola vez ha ahorrado mucho tiempo de captura de datos. 

También se debe tomar en cuenta el poder de calcular de la computadora al decidir lo que 
no se va a volver a capturar. Las computadoras son expertas en cálculos largos, usando datos 
ya capturados. 

Por ejemplo, la persona que hace la entrada de datos podría capturar los números de 
vuelo y de cuenta de un viaje aéreo tomado por un cliente que pertenece a un programa 
de incentivo de viajero frecuente. Después, la computadora calcula el número de millas 
acumulado por cada vuelo, lo agrega a las millas en la cuenta del cliente y actualiza las mi¬ 
llas totales acumuladas a la cuenta. La computadora también podría marcar una cuenta 
que, en virtud del gran número de millas volado, ahora es merecedora de un premio. Aun¬ 
que toda esta información podría aparecer en la cuenta actualizada del cliente, los únicos da¬ 
tos nuevos capturados fueron los números de vuelo de los vuelos hechos. 

En los sistemas que usan una interfaz gráfica de usuario (GUI), normalmente los códigos 
se almacenan en una base de datos ya sea como una función o como una tabla separada. Hay 
pros y contras al crear demasiadas tablas, debido a que el software debe buscar los registros de 
coincidencia de cada tabla, lo cual podría dar como resultado a un acceso lento. Si los códi- 
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se usa para seleccionar un 
código que agrega o cambia un 
artículo en un registro. 
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.[ Be tsey' s Be ad Company i 0 

i_ Ursa Optica! : 1 

Jronsmjth Manufacturing j 1 

; Industrial Clearring Supply_[l__ 

lOrientalImpotls_ _'0 

: Gordon Builders 13 


..._ • Musíc Uníimlted.... i 1 

i : FilmMagic Video Rental _jj_ 

! IWorld’s Trend !o 

3 Masterpiece Manuscnpts 11 

Ma¡ Recoidíng Studios ¡2 

J Wallaby Outfitters : i 

Naihan s House oí Pets 1 

.... Katnna Kitchen Deslgn 1 

: Central Pacific University i 1 __ 

!.; Bartlett County Maintenance1 

|_Healthy Food Foundation : 1 


General Customcr _l^reet 

Street 

• Educaíi’on Customer !t 

; Government Customer 

'Taje Exempt Customer Way 

iVolume Customer a _ i l ay ñnar! 

'949 ;3055 Blh Avenue 

J515...i 2885 N._Washington_. 

¡051 : 28 Central Avenue 

191_2550 N. 33 Street_ 

j 191..' 939 Central Avenue 

i 191 88 W. 2nd Street 

477 3 Apple Way 
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051 .1000 First Sireet 
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gos son relativamente estables y raramente cambian, se podrían almacenar como una fun¬ 
ción de la base de datos. Si los códigos cambian con frecuencia, se almacenan en una tabla 
para que se puedan actualizar fácilmente. 

La figura 15.14 muestra cómo se usa una lista desplegable para seleccionar los códigos 
para agregar o cambiar un registro en la tabla CLIENTE. Observe que el código se almacena, 
pero la lista desplegable muestra el código y su significado. Este método ayuda a asegurar 
la precisión, debido a que el usuario no tiene que adivinar el significado del código y no hay 
ninguna oportunidad de teclear un código inválido. 

EVITANDO CUELLOS DE BOTELLA Y PASOS ADICIONALES 

Un cuello de botella en la entrada de datos es una alusión adecuada a la apariencia física de 
una botella. Los datos se introducen con rapidez en la boca ancha del sistema sólo para que 
se retrasen en su "cuello" debido a un caso creado artificialmente de insuficiente capacidad 
de procesamiento para el volumen o detalle de los datos a ser capturados. Una forma en que 
se puede evitar un cuello de botella es asegurar que haya suficiente capacidad para manejar 
los datos que se van a capturar. 

Las formas de evitar los pasos extras no sólo se determinan en el momento del análisis, 
sino también cuando los usuarios empiezan a interactuar con el sistema. Entre menos pasos 
haya en la entrada de datos, habrá menores oportunidades para la introducción de errores. Así 
que, más allá de la consideración obvia de ahorrar trabajo, evitar pasos extras también es una 
forma de conservar la calidad de los datos. Una vez más, usar un sistema en línea de tiempo 
real que capture los datos del cliente sin necesidad de contestar un formulario es un ejem¬ 
plo excelente de ahorrar pasos en la entrada de datos. 

EMPEZANDO CON UN BUEN FORMULARIO 

La captura de datos eficaz sólo se logra si se piensa con anterioridad lo que el documen¬ 
to fuente debe contener. El operador de entrada de datos captura los datos del documento 
fuente (normalmente algún tipo de formulario); este documento es la fuente de una gran 
cantidad de datos del sistema. Los sistemas en línea (o métodos especiales de entrada de 
datos tal como los códigos de barras] podrían evadir la necesidad de un documento fuen- 
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te, pero de cualquier forma a menudo se crea algún tipo de formulario impreso, tal como 
un recibo. 

Con los formularios eficaces, no es necesario volver a capturar la información que la 
computadora ya ha almacenado o los datos tales como hora o fecha de entrada que la compu¬ 
tadora puede determinar automáticamente. En el capítulo 11 se discutió con detalle cómo 
se deben diseñar un formulario o un documento fuente para maximizar su utilidad para 
capturar los datos y minimizar el tiempo que los usuarios necesitan emplear para introducir 
los datos en ellos. 

ELECCIÓN DE UN MÉTODO DE ENTRADA DE DATOS 

Existen varios métodos de entrada de datos eficaces y la elección de alguno depende de mu¬ 
chos factores, incluyendo la necesidad de velocidad, precisión y entrenamiento del operador; 
el costo del método de entrada de datos [ya sea que requiera mucho trabajo o materiales], y 
los métodos actualmente en uso en la organización. 

Teclados Teclear es el método más viejo de entrada de datos y ciertamente es uno con los 
que los miembros de la organización están más familiarizados. Durante los años se han 
hecho algunas mejoras para perfeccionar los teclados. Las características incluyen teclas de 
función especial para abrir programas, teclas usadas para navegar y explorar la Web y teclas 
que se pueden programar con macros para reducir el número de tecleos necesarios. Los te¬ 
clados ergonómicos, teclados infrarrojos o habilitados para Bluetooth y los ratones también 
son grandes avances. 

Reconocimiento óptico de caracteres El reconocimiento óptico de caracteres (OCR) 
permite a un usuario leer la entrada de un documento fuente con un escáner óptico en lu¬ 
gar de los medios magnéticos que hemos discutido hasta ahora. Usar los dispositivos de OCR 
puede acelerar la entrada de datos de 60 a 90 por ciento sobre algunos métodos del tecleo. 

Como se muestra en la figura 15.15, lo que se necesita es un documento fuente que se 
pueda escanear ópticamente cuando se complete ya sea a máquina o a mano usando letra 
de molde. 

La velocidad aumentada de OCR viene de no tener que codificar o teclear los datos de 
los documentos fuente. Elimina muchos pasos que consumen tiempo y pueden generar 
errores en otros dispositivos de entrada. Con ello, OCR exige pocas habilidades del emplea¬ 
do y correspondientemente menos entrenamiento, produciendo menos errores y menos 
tiempo requerido por los empleados en los esfuerzos redundantes. También delega la res¬ 
ponsabilidad de capturar datos de calidad en la unidad que los está generando. OCR, que 
ahora está disponible para todos, tiene un uso adicional muy práctico: la transformación de 
facsímiles en documentos que se pueden editar. 

Otros métodos de entrada de datos También hay otros métodos de entrada de datos que 
se han usado ampliamente. La mayoría de estos métodos reduce los costos de mano de obra 
pues requieren menos habilidades del operador o poco entrenamiento, mueven la entrada 
de datos más cerca a la fuente de datos y eliminan la necesidad de un documento fuente. De 
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El recon oeí m i e nto ó pti co 
de caracteres (OCR) de 
documentos originales 
con caracteres especiales 
facilita la entrada de datos 
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este modo, se han vuelto métodos de entrada de datos rápidos y muy fiables. Los métodos 
de entrada de datos discutidos en las siguientes subsecciones incluyen el reconocimiento de 
caracteres de tinta magnética, formularios de reconocimiento de marcas, formularios pre¬ 
perforados, códigos de barras y tiras de datos. 

Reconocimiento de caracteres de tinta magnética. Los caracteres de tinta magnética 
se encuentran en la parte inferior de cheques bancarios y en algunas facturas de tarjeta de 
crédito. Este método es semejante a OCR en que los caracteres especiales se leen, pero su 
uso está limitado. La entrada de datos a través del reconocimiento de caracteres de tinta 
magnética (MICR) se hace a través de una máquina que lee e interpreta una sola línea de 
material codificado con tinta que se hace de partículas magnéticas. 

Algunas ventajas de usar MICR son (1) es un método fiable y de gran velocidad que no 
es susceptible a aceptar las marcas perdidas (porque no se codifican magnéticamente); (2) 
si se requiere en todos los cheques cobrados, sirve como una medida de seguridad contra los 
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de marcas que se puede leer 
mediante un escáner que acelera 
la entrada de datos. 
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cheques malos, y (3) el personal de entrada de datos puede ver los números al código si es 
necesario verificarlos. 

Formas de reconocimiento de marcas. Las formas de reconocimiento de marcas 
permiten entrada de datos mediante el uso de un escáner que siente dónde se han hecho 
las marcas en los formularios especiales. Como se muestra en la figura 15.16, un uso común 
es para marcar las hojas de respuesta de los cuestionarios. Se necesita poco entrenamien¬ 
to por parte del personal de entrada y un gran volumen de formularios se puede procesar 
rápidamente. 

Una desventaja de las formas de reconocimiento de marcas es que aunque los lecto¬ 
res pueden determinar si se ha hecho una marca, no pueden interpretar la marca en la 
forma en que lo hacen los lectores de caracteres ópticos. Por lo tanto, las marcas desubi¬ 
cadas en los formularios se pueden introducir como datos incorrectos. Además, se limi¬ 
tan las opciones a las respuestas proporcionadas en la forma de reconocimiento de mar¬ 
cas, los formularios tienen dificultad al capturar datos alfanuméricos debido al espacio 
requerido para un conjunto completo de letras y números y és fácil para aquellos que 
completan una forma de reconocimiento de marcas confundirse y poner una marca en 
una posición incorrecta. 

Códigos de barras. Los códigos de barras aparecen típicamente en las etiquetas de los 
productos, pero también aparecen en las pulseras de identificación de pacientes en los hospita¬ 
les y en casi cualquier contexto en que una persona u objeto necesita ser verificado dentro 
y fuera de cualquier tipo de sistema de inventario. Los códigos de barras pueden pensarse 
como metacódigos o códigos que codifican códigos, debido a que aparecen como una serie 
de bandas estrechas y anchas en una etiqueta que codifica números o letras. Estos símbolos 
a su vez tienen acceso a datos del producto almacenados en la memoria de la computadora. 
Un rayo de luz de un escáner o una pluma óptica se pasa por las bandas en la etiqueta para 
confirmar o registrar los datos sobre el producto a escanear. 

Una etiqueta que se codifica por medio de código de barras, tal como la que se muestra 
en la figura 15.17, incluye los siguientes elementos de codificación para un producto particu¬ 
lar de comestibles: el número de identificación del fabricante, el número de identificación 
del producto, un dígito para verificar la precisión del escáner y códigos para marcar el prin¬ 
cipio y fin del escáner. 

La codificación de barras ofrece un grado extremadamente alto de precisión para la entra¬ 
da de datos. Ahorra los costos de mano de obra para minoristas porque cada artículo no tiene 
que ser marcado individualmente. Además, la codificación de barras permite capturar automá¬ 
ticamente datos que se pueden usar para resurtir el almacén, registrar con mayor precisión el 
inventario y pronosticar necesidades futuras. Los cambios en precios de venta u otros cambios 
en el significado de los códigos de barras se introducen en el procesador central, de manera que 
se ahorra el problema de marcar numerosos artículos individualmente. 

Un nuevo uso de los códigos de barras es rastrear las compras con tarjeta de crédito de 
un individuo con el propósito de construir un perfil del cliente que a su vez se puede usar 
para refinar el mercadeo a ese individuo o tipo de cliente. Nuevos dispositivos de entrada se 




Los cócl'fíos de barras, como se 
muestra en esta etiqueta para un 
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están desarrollando constantemente. Por supuesto, ha sido posible transferir las imágenes 
fotográficas durante algún tiempo ahora que usa sistemas como el proceso Kodak Photo 
CD, pero usar una cámara digital elimina el paso intermedio de usuarios que necesitan digi- 
talizar sus propias fotografías. 

Uso de terminales inteligentes Las terminales inteligentes se pueden considerar un paso 
delante de las terminales sin inteligencia y un paso atrás de las estaciones de trabajo inteli¬ 
gentes y PCs en sus capacidades. En muchos casos, las terminales inteligentes eliminan la 
necesidad de un documento fuente. 

La ventaja más grande de usar las terminales inteligentes es que, mediante el uso de un 
microprocesador, pueden relevar a la unidad central de procesamiento [CPU) en muchas de 
las cargas de editar, controlar, transformar y almacenar datos; procesos que requieren las 
terminales sin inteligencia. Las terminales sin inteligencia confían en la CPU para toda la ma¬ 
nipulación de datos, incluyendo editar y actualizar. 

La configuración para las terminales inteligentes es un microprocesador, pantalla y te¬ 
clado. La terminal inteligente tiene acceso a la CPU a través de una red y puede ser en línea 
en forma directa, o en línea de manera diferida. En una terminal inteligente en línea, todos 
los pasos en la entrada, procesamiento, verificación y la salida se hacen inmediatamente con 
el cliente presente. Entre más cerca de la fuente de los datos se realice su captura, más pro¬ 
bable será su precisión. Un ejemplo muy conocido de una terminal inteligente en línea es 
un sistema que vende boletos en una aerolínea. 

Las terminales inteligentes en línea diferida permiten introducir los datos y que se ve¬ 
rifiquen inmediatamente, pero el procesamiento es por lotes y se hace después (lo cual es 
menos caro). Las cajas registradoras electrónicas combinan estos atributos, con las capacida¬ 
des de entrada y salida en las terminales de punto de venta. 


CÓMO ASEGURAR LA CALIDAD DE LOS DATOS A TRAVÉS 
DE LA VALIDACIÓN DE LA ENTRADA 

Hasta ahora, hemos discutido cómo asegurar la captura eficaz de datos en el documento 
fuente y la entrada eficaz de datos en el sistema mediante diversos dispositivos de entrada. 
Aunque estas condiciones son necesarias para asegurar la calidad de los datos, no son sufi¬ 
cientes por sí mismas. 

Los errores no se pueden evitar por completo y no debe darse demasiada importancia 
a la detección de errores durante la entrada, antes del procesamiento y del almacena¬ 
miento. Los enredos ocasionados por la entrada incorrecta pueden convertirse en una pesadi¬ 
lla, además de que muchos de los problemas tardan en aparecer. El analista de sistemas 
debe asumir que los errores en los datos ocurrirán y debe trabajar con los usuarios para 
diseñar pruebas de validación de entrada para prevenir datos erróneos, debido a que los 
errores iniciales, que pasan mucho tiempo sin ser descubiertos, son caros y lleva tiempo 
corregirlos. 

No puede imaginar todo lo que pueda salir mal con la entrada, pero debe cubrir los tipos 
de errores que dan lugar al porcentaje más grande de problemas. En la figura 15.18 se da un 
resumen de problemas potenciales que se deben considerar al validar la entrada. 

VALIDACIÓN DE LAS TRANSACCIONES DE ENTRADA 

Validar las transacciones de entrada se hace principalmente mediante software que es la 
responsabilidad del programador pero es importante que el analista de sistemas sepa qué 
problemas comunes podrían invalidar una transacción. Los negocios comprometidos 
con la calidad incluyen la verificación de validez en forma rutinaria como parte de su 
software. 

Con las transacciones de entrada puden ocurrir tres problemas principales: enviar los 
datos incorrectos al sistema, enviar los datos por una persona no autorizada o pedir al siste¬ 
ma que desempeñe una función inaceptable. 

ASPECTOS ESENCIALES DEL DISEÑO 





Este tipo 

rie validación Puede prevenir estos problemas 

.-V^j'jVr )n:¡ li v-i.'í ciri'üis i.VCjÜ ;:.i ': . . V: 

: transacciones 1 " Datos enviados por una persona no : 

| de. entrada T ; • aútorizada . 

■. , . ‘ ..Pedir'a la computadora que ejecute ' r 

: : j una acción inaceptable Í V-t | 

Validar los datos Pérdida de datos 
de entrada Longitud de campo incorrecta 

Datos con una composición inaceptable 
Datos fuera de rango 
Datos inválidos 

Datos que no coincidan con los datos 
almacenados 

Envío de datos incorrectos Un ejemplo del envío de datos incorrectos al sistema es el in¬ 
tento de introducir el número del seguro social de un paciente en el sistema de nómina de 
un hospital. Este error normalmente es accidental, pero se debe marcar antes de que se pro¬ 
cesen los datos. 

Envío de datos por una persona no autorizada El sistema también debe tener forma de 
saber si los datos, aunque correctos, son enviados por una persona no autorizada. Por ejem¬ 
plo, sólo el supervisor de farmacia debe poder introducir los totales del inventario para las 
sustancias controladas en la farmacia. La invalidación de transacciones enviadas por un indi¬ 
viduo no autorizado se aplican en situaciones relacionadas con la privacidad y la seguridad 
de los sistemas de nómina y los registros de evaluación del desempeño de empleados que se 
usan para determinar los sueldos, promociones o disciplina; archivos que contienen secretos 
comerciales, y archivos que contienen información secreta, tal como los datos de la defensa 
nacional. 

Pedir al sistema que desempeñe una función inaceptable El tercer error que invalida las 
transacciones de entrada es pedir al sistema que desempeñe una función inaceptable. Por 
ejemplo, podría ser lógico para un gerente de recursos humanos actualizar el registro exis¬ 
tente de un empleado actual, pero no sería válido pedir al sistema crear un nuevo archivo 
en lugar de sólo actualizar un registro existente. 
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VALIDACIÓN DE DATOS DE ENTRADA 

Es esencial que los datos de entrada, junto con las transacciones pedidas, sean válidos. Varias 
pruebas se pueden incorporar en el software para asegurar esta validez. Nosotros considera¬ 
mos ocho formas posibles de validar la entrada. 


Prueba de datos perdidos El primer tipo de prueba de validez examina los datos para ver 
si hay algún elemento perdido. En algunas situaciones todos los elementos deben estar 
presentes. Por ejemplo, un archivo del seguro social para pagar la jubilación o beneficios de 
invalidez sería inválido si no incluye el número del seguro social del portador. 

Además, el registro debe incluir los datos clave que distinguen un registro de todos los 
demás y el código de función que le dice a la computadora qué hacer con los ciatos. El 
analista de sistemas necesita interactuar con los usuarios para determinar qué artículos son 
esenciales y para averiguar si alguna vez ocurren casos excepcionales que permitirían conside¬ 
rar los datos válidos aun cuando falten algunos elementos. Por ejemplo, una segunda línea 
de dirección que contiene un número de departamento o la inicial del segundo nombre de 
una persona tal vez no sea una entrada requerida. 
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en que los valores ni se restringen ni se predicen. Este tipo de prueba es útil para verificar 
respuestas donde los datos se dividen en un número limitado de clases. Por ejemplo, una 
empresa de corretaje sólo divide las cuentas en tres clases: clase 1 = cuenta activa, clase 2 = 
cuenta inactiva y clase 3 = cuenta cerrada. Si los datos se asignan por error a cualquier otra 
clase, los valores son inválidos. Las verificaciones de valores normalmente se desempeñan 
por datos discretos, los cuales son datos que tienen sólo ciertos valores. Si hay muchos valo¬ 
res, normalmente se almacenan en una tabla de archivo de códigos. Tener los valores en un 
archivo proporciona una forma fácil para agregar o cambiar los valores. 


Verificación de referencia cruzada Una verificación de referencia cruzada se usa cuando 
un elemento tiene una relación con otro. Para realizar una validación de referencia cruzada, 
cada campo debe ser correcto en sí mismo. Por ejemplo, el precio para cada artículo vendido 
debe ser mayor al costo pagado por el mismo. El precio se debe introducir, debe ser numé¬ 
rico y mayor que cero. El mismo criterio se usa para validar el costo. Cuando el precio y el 
costo son válidos, se podrían comparar. 

Una verificación geográfica es otro tipo de verificación de referencia cruzada. En Esta¬ 
dos Unidos, la abreviación estatal se podría usar para asegurar que un código de área de te¬ 
léfono es válido para ese estado y que los primeros dos dígitos del código postal son válidos 
para el estado. 


Prueba de comparación con los datos almacenados La próxima prueba para la validez de 
datos de entrada que consideramos es el comparar lo recibido con datos que la computadora 
ya ha almacenado. Por ejemplo, un número de parte introducido recientemente se puede 
comparar con el inventario de partes completas para asegurar que el número existe y se está 
introduciendo correctamente. 


Creación de códigos de autovalidación (dígitos de verificación) Otro método para asegurar 
la precisión de datos, particularmente números de identificación, es usar un dígito de verifi¬ 
cación en el propio código. Este procedimiento involucra iniciar con un código numérico 
original, desempeñar algo de matemática para llegar a un dígito de verificación derivado y 
después agregar el dígito de verificación al código original. El proceso matemático implica 
multiplicar cada uno de los dígitos en el código original por algunos pesos predeterminados, 
sumar estos resultados y después dividir esta suma entre un número de módulo. El número 
de módulo se necesita porque la suma normalmente es un número grande y necesitamos 
reducir el resultado a un solo dígito. Por último, el resto se substrae del número de módu¬ 
lo, dándonos el dígito de verificación. 

La figura 15.19 muestra cómo un número de parte de cinco dígitos para una manguera 
del radiador (54823) se convierte a un número de seis dígitos que contiene un dígito de ve¬ 
rificación. En este ejemplo, los pesos escogidos fueron el sistema "1-3-1"; en otros términos, 
los pesos alternan entre 1 y 3. Después de que los dígitos 5, 4, 8, 2 y 3 fueron multiplicados 
por 1, 3,1, 3 y 1, se volvieron 5,12, 8, 6 y 3. Estos nuevos dígitos suman 34. Después, 34 se 
divide entre el número de módulo escogido, 10, con el resultado 3 y un residuo de 4. El re¬ 
siduo, 4, se resta del número de módulo, 10, dando un dígito de verificación de 6. El dígito 6 
ahora cambia de dirección hacia el final del número original, que proporciona el código del 
producto oficial para la manguera del radiador (548236). 


Uso de los dígitos de verificación. El sistema de dígito de verificación funciona de la 
siguiente forma. Suponga que teníamos el número de parte 53411. Este número se tiene 
que teclear en el sistema, y mientras eso se hace, pueden ocurrir diferentes tipos de errores. 
Un posible error es el error de dedo de un solo dígito; por ejemplo, el empleado teclea 
54411 en lugar de 53411. Sólo el dígito en el lugar de los miles es incorrecto, pero este error 
podría resultar en el envío de la parte incorrecta. 

Un segundo tipo de error es la transposición de dígitos. Normalmente ocurre cuan¬ 
do el número pretendido 53411 se teclea como 54311, sólo porque se aprietan dos teclas 
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en orden inverso. Los errores de transposición también son difíciles de descubrir para los 
humanos. 

Como se muestra en la figura 15.20, estos errores se evitan mediante el uso de un dígito 
de verificación porque cada uno de estos números —el correcto y el equivocado— tendría un 
número diferente de dígito de verificación. Si el número de parte 53411 se modificó a 
534118 (incluyendo el dígito de verificación 8) y ya sea que ocurran los dos errores recién 


Evite errores üuTíiünée uf; 
entrada de datos mediante el 
uso de un dígito de verificación. 


Estado 


Correcto 


Dígito de Nuevo 

Código original verificación código 


5 3 4 11 


8 

Errar de un solo dígito 5 4 4 11 5 

Transpuesto 5 4 3 .11. , ■■ 6. 


534118 
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Método ds dígito Cálculos para el dígito de verificación que se va a agregar 
de verificación al número original 29645 


. M úTIicIíí 

'' 2 - 1 - 2 " : 
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'-'2 b.-. 

\__2 " 

f 2 + 


; ; 4 ; 

_X.J . 

I + 


10 - 39/10 ¿ 3 \ sobran . J9_) 

Ef dígito de verificación es 1 
■' El código con el dígito de 
• verificación es 296451 


Ejávipios de'fr^Gtó? cé peso 

y -'UTeros i ieTTióci'iftO: 


Módulo 10 2 9 6 4 5 

"3-1-3” x_3 _x_1 _x3^ x 1 xj. 10 

6 + 9+18 + ~4 + 15 - 52/10 - 5 y sobran (2) 

El dígito de verificación es 8 
El código con el dígito de 
verificación es 296451. 


Módulo: 11 
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Módulo 10 
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2 

x32 
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x I 6 
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5 
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11 

10 = 282/11 = 25 y sobran J7) 

El dígito de verificación es 4 
El código con e| dígito de 
verificación es 296451. 


descritos, el error se percibiría. Si el segundo dígito fuera el error como un 4, la computado¬ 
ra no aceptaría 544118 como un número válido, porque el dígito de verificación para 54411 
sería 5, no 8. De forma similar, si se transpusieran el segundo y tercer dígitos, como en 
543118, la computadora rechazaría también el número porque el dígito de verificación pa¬ 
ra 54311 seria 6, no 8. 

El analista de sistemas escoge los pesos y el número de módulo, pero una vez escogidos, 
no deben cambiar. Pueden verse algunos ejemplos del uso de diferentes pesos y números 
del módulo en figura 15.21. 

El sistema de dígito de verificación no está seguro. Es concebible que dos números de 
parte (732463 y 732413, por ejemplo] puede tener el mismo dígito de verificación. Un so¬ 
lo error de dedo en el penúltimo dígito no se descubriría en ese caso. 

El sistema de dígito de verificación también tiene un costo. El espacio agregado por 
el dígito de verificación debe ser considerado, así como el cómputo adicional involucra¬ 
do en el cálculo y verificación del dígito. El método de dígito de verificación es útil cuando 
los códigos originales son cinco o más dígitos, cuando los códigos son numéricos simples 
sin significado, y cuando el costo de un error de dedo y los errores de transposición son 
altos. 

Las siete pruebas para inspeccionar validez de entrada pueden ayudar mucho a proteger 
el sistema de la entrada y almacenamiento de datos erróneos. Siempre asuma que es más pro¬ 
bable que ocurran errores en la entrada a que los datos no tengan errores. Es su responsabili¬ 
dad entender qué errores invalidarán los datos, y cómo usar la computadora para protegerse 
de esos errores y así limitar su intrusión en los datos del sistema. 


PROCESO DE VALIDACIÓN 

Es importante validar cada campo hasta que sea válido o se haya descubierto un error. El or¬ 
den de prueba de los datos es primero verificar si hay datos perdidos. Luego, una prueba de 
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la sintaxis para verificar la longitud de los datos de entrada y verificar su clase y composi¬ 
ción apropiadas. Sólo después de que la sintaxis es correcta se prueba la semántica, o signi¬ 
ficando, de los datos. Esto incluye una prueba de rango, razonabilidad o valor, seguida por 
una validación del dígito de verificación. 

Normalmente la validación de un solo campo se hace con una serie de SI... ENTON¬ 
CES... SI-NO, pero hay también métodos de validación de patrones. Normalmente estos 
patrones se encuentran en el diseño de la base de datos (como en el Access de Microsoft), 
pero puede ser incluidos en lenguajes de programación, como Perl, JavaScript y esquemas 
de XML. Los patrones se llaman las expresiones regulares y contienen símbolos que represen¬ 
tan el tipo de datos que deben estar presentes en un campo. La figura 15.22 ilustra caracteres 
usados en expresiones regulares de JavaScript. 

Un ejemplo de validación de patrones probaba que una dirección del correo electrónico es 

[ A-Za-zO-9] \w {2,] @ [A-Za-zO-9] {3, }\. [A-Za-z] {3}/ 

El significado de este modelo es como sigue: la primera letra debe ser cualquier letra 
mayúscula, letra minúscula o número ([A-Za-zO-9]). Esto se sigue por dos o más caracteres 
que pueden ser cualquier letra, numero, o un guión bajo (\w{2,}}. Debe haber entonces el 
símbolo @ siguió por al menos tres letras o números, un punto y exactamente tres caracte¬ 
res después del punto. 

Una verificación de referencia cruzada asume que la validez de un campo puede de¬ 
pender del valor de otro campo. Un ejemplo de una verificación de referencia cruzada es el 
verificar la validez de una fecha. En un caso muy especial, la validez del día del mes depen¬ 
de del año. Es decir, el 29 de febrero sólo es válido durante años bisiestos. Una vez que se 
han verificado los campos simples, puede realizar las verificaciones de referencia cruza¬ 
da. Obviamente, si uno de los campos es incorrecto, la verificación de referencia cruzada 
no tiene sentido y no se debe realizar. 



Estos caracteres se usan en una 
validación de expresión regular 
(patrón). 


Código Significado usado en una validación 

de carácter de expresión regular 

\d Cualquier dígito de 0 a 9 

\D . . Cualquier carácter sin dígito 

\w Cualquier letra, número o guión bajo 

\W Cualquier carácter que no sea letra, número o 

.A;, guión bajo hace coincidir cualquier carácter . 

Hace coincidir caracteres dentro de los corchetes 
[caracteres] Hace coincidir el rango de caracteres 

[char-charl Aceptara cualquier .letra o dígito 

[a-z][A-Z][0-9] Hace coincidir cualquier otra cosa a parte de caracteres 
[Caracteres] / Hace, coincidir cualquier ;otra cosa fuera del rango de caracteres 
; [ A char-char] : Aceptará cualquier cosa excepto letras, en minúsculas 

[ A a-z] Hace coincidir exactamente n ocurrencias del 

[n] .. carácter que preceda al símbolo 

Hace coincidir por lo menos n ocurrencias del carácter 
{n,} Cualquier carácter de formateo por espacio en 

\s blanco (tabulación, línea nueva, retorno, etcétera) : 

Cualquier carácter de formato que no represente 
• '•ASvUV- ■ ü' " v' .'espacio en blanco 
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"¿Qué vamos a hacer, Mercedes?”, pregunta Edsel con desgano. Mer¬ 
cedes y Edsel revisan conjuntamente el documento impreso de la última 
facturación de su negocio, Estacionamientos Dentón y Dentón. Han esta¬ 
do adquiriendo servicios de facturación de una pequeña compañía de 
servicios de cómputo local desde que compraron.tres estacionamientos 
en un área metropolitana de tamaño medio. Estacionamientos Dentón y 
Dentón renta lugares en forma diaria, mensual y anual a corporaciones e 
individuos. 

Mercedes contesta: "No sé cuál será nuestro siguiente paso, pero to¬ 
da la facturación está mal.Tal vez podríamos hablar con la gente del 
servicio de cómputo'". ■ 

"Ellos dicen que podrían averiguar cómo calcular estos cargos si vie¬ 
ran lo que los propietarios anteriores hacían a mano,; y también dicen 
que no quisieran utilizara! mismo tiempo el sistema anterior y el nuevo", 
comenta Edsel, sacudiendo la cabeza. "Sin embargo, eso no es cierto. Al 
menos no puedo imaginarlo. Tal vez tú sí puedas." . ' 

Mercedes acepta la opinión de verificar el reporte y empieza a revisar 
el informe con detalle. "Bueno, por alguna razón no .se han dado cuenta 
que aquí tenemos automóviles de todas partes. Dondequiera .que hay un 
auto con placas de otro estado, la computadora parece detenerse sin saber 
qué hacer. Mira, las placas de nuestro estado empiezan con un número y 


una letra, ¿correcto? Bueno, esta de Nueva York empieza con tres letras. 
La computadora no la reconoce", dice Mercedes. 

Edsel comprende y comienza a pensar en el negocio mientras ob¬ 
serva el documento impreso. "Sí, y mira aquí. Esta persona no tiene un 
número de cuenta anual, sólo uno mensual, así que no hay factura", 
dice. "¿También hemos tenido clientes mensuales y la computadora no 
lo sabe?" 

"Y mira esto. Aún se están haciendo cobros diarios por los tres días 
de noviembre a pesar dé. que les indicamos que ya no había cupo para 
clientes diarios. Esto no es posible", afirma Mercedes. 

Edsel continúa hojeando el documento impreso, pero Mercedes lo de¬ 
tiene’:; "Ya no mires. Estoy llamando a la gente del servicio de cómputo 
para que arreglen este embrollo". 

¿Cómo puede representar los problemas que se han encontrado en el 
sistema de facturación de los estacionamientos? Formule su respuesta 
en un párrafo: ¿Qué; pruebas: para validar los datos se podrían incluir en 
él software dé un sistema de facturación modificado, para los estaciona¬ 
mientos? Menciónelas. ¿Que podrían hacer diferente el programadory los 
analistas de la compañía de servicios de cómputo para que el cliente 
no tenga que corregir la salida deficiente? Realice un análisis en tres 
párrafos acerca de lo que se hizo y de lo que se debería haber hecho. 


VENTAJAS DE LA PRECISION EN LOS ENTORNOS DE COMERCIO ELECTRONICO 

Uno de los muchos bonos de las transacciones de comercio electrónico es la mayor precisión 
de los datos, debido a cuatro razones: 

1. Los clientes generalmente codifican o teclean los datos. 

2. Los datos introducidos por los clientes se almacenan para su uso posterior. 

3. Los datos introducidos en el punto de venta se reúsan a lo largo del proceso de surtido 
del pedido. 

4. La información se usa como retroalimentación para los clientes. 

Un analista necesita tomar conciencia de las ventajas que han sido el resultado del comercio 
electrónico y la captura electrónica y uso de información. 


CLIENTES QUE CODIFICAN SUS PROPIOS DATOS 

Primero, los clientes conocen mejor su propia información que nadie más. Saben deletrear su 
dirección, saben si viven en un "Andador" o una "Calle" y saben su propio código telefónico. Si 
esta información se transmite por teléfono, es más fácil cometer un error en la dirección; si se 
introduce usando un formulario impreso enviado por facsímil, los errores pueden ocurrir si 
la transmisión del facsímil es difícil de leer. Sin embargo, si los usuarios introducen su propia 
información aumenta la precisión. 


ALMACENAMIENTO DE DATOS PARA SU USO POSTERIOR 

Una vez que los clientes introducen la información, se puede almacenar en sus propias 
computadoras personales. Si regresan a ese sitio de comercio electrónico y completan el 
mismo formulario para completar una segunda transacción, darán testimonio de la ventaja 
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de almacenar esta información. Cuando empiezan a teclear su nombre, las listas desplegables 
los incitarán con su nombre lleno aunque se entraron en sólo un par de caracteres. Haciendo 
clic en esta sugerencia, se introduce el nombre completo y no se necesita teclear nada más 
para este campo. Esta característica de autocompletar puede hacer pensar en las coinciden¬ 
cias también para la tarjeta de crédito e información de la contraseña y esta información se 
encripta para que los sitios Web no puedan leer la información almacenada en la compu¬ 
tadora del usuario. 

Si las compañías quieren guardar la información para habilitar transacciones más rápidas 
y exactas, usan archivos llamados cookies o galletas. La información específica de tarjeta 
del crédito y otra información personal sólo pueden ser accedidas por la compañía que puso 
la galleta en la computadora del usuario. 


USO DE DATOS A TRAVÉS DEL PROCESO DE SURTIDO DEL PEDIDO 

Cuando las compañías capturan la información de un pedido del cliente, pueden usar y 
reusar esa información a lo largo del proceso de surtido del pedido. Por lo tanto, la informa¬ 
ción recopilada para completar un pedido también puede usarse para enviar una factura a 
un cliente, obtener el producto del almacén, enviar el producto, enviar la retroalimenta- 
ción al cliente y notificar al fabricante que debe resurtir el producto. También se puede 
usar de nuevo para enviar un catálogo al cliente o enviar una oferta especial por correo 
electrónico. 

Estas mejoras del comercio electrónico reemplazan el enfoque tradicional que usó 
un proceso de adquisiciones basado en papel con las órdenes de compra enviadas me¬ 
diante facsímil o correo. Este proceso electrónico no sólo acelera la entrega del producto, 
sino que también aumenta la precisión para que el producto se entregue a la dirección 
correcta. En lugar de leer un facsímil o mandar por correo el formulario, un cargador usa 
la versión electrónica más exacta de los datos. La información electrónica permite una 
buena administración de la cadena de abastecimiento, incluyendo la verificación del produc¬ 
to y disponibilidad del recurso electrónicamente y automatiza el diseño, planificación y 
pronóstico. 


PROPORCIONANDO RETROALIMENTACIÓN A LOS CLIENTES 

La confirmación del pedido y actualización del estado del mismo son formas en que se pue¬ 
de mejorar la retroalimentación a clientes. Si un cliente recibe nota de un error en un pedido 
hecho recientemente, el pedido puede corregirse inmediatamente. Por ejemplo, suponga 
que equivocadamente un cliente envía un pedido por dos copias de un DVD en lugar de 
uno. Después de enviar el pedido, el cliente recibe un correo electrónico que confirma el 
pedido. El cliente percibe el error, inmediatamente contacta a la compañía y corrige el pedi¬ 
do, por consiguiente evita tener que devolver la copia extra del DVD. La precisión se mejora 
con una buena retroalimentación. 




RESUMEN 

Asegurar la calidad de la entrada de datos al sistema de información es crítico para asegurar 
la salida de calidad. La calidad de los datos capturados se puede mejorar mediante el logro 
de los tres objetivos principales de entrada de datos: codificación eficaz; captura de datos 
eficaz y eficiente, y la validación de datos. 

Una de las mejores formas para acelerar la entrada de datos es mediante el uso eficaz de 
la codificación, la cual pone los datos en secuencias cortas de dígitos y/o letras. Los códigos 
de secuencia simple y los códigos de derivación alfabética se pueden usar para rastrear el 
progreso de un artículo dado a través de un sistema. Los códigos de clasificación y los códi¬ 
gos de secuencia en bloque son útiles para distinguir unas clases de artículos de otras. Los 
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"A veces creo que soy la persona con más suerte sobre la Tierra. A pesar dé que llevó cinco 
años aquí, todavía disfruto de lo que hago y de la gente que conozca Sí, sé queSnowden es 
muy exigente. Usted Ha tenido algunas experiencias al respecto, ¿verdad? Por una parte, : él 
ama los códigos. Yo creó qué son un dolor de cabeza. Siempre los olvido o trato ele inventar 
nuevos o algo así. Sin embargo, algunos de los médicos opinan que son excelentes. Tal vez se 
deba a todas las abreviaturas en latín que estudiaron en la escuela de medicina. Escuché qué 
su principal tarea de esta semana consiste en meter la información éneí sistema de elabora¬ 
ción de informes del proyecto. La Unidad de Capacitación quiere sus ideas, y las quiere rápido. 
Buena suerte con esto. Ah, y estoy seguró de que cuando Snowdén vuelva de Tailandia 
deseará darle un vistazo a lo que ha estado haciendo su equipo." /• 


EXPERIENCIA CON HYPERCASE® 
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PREGUNTAS DE HYPERCASE 

1. Con ayuda de una herramienta CASE, un paquete de software cómo Microsoft Access, 
o un formulario en papel, diseñe un procedimiento de captura de datos para el sistema 
de elaboración de informes del proyecto propuesto para la Unidad de Capacitación. 
Suponga que estamos muy preocupados por el personal médico, quienes no desean in¬ 
vertir mucho tiempo capturando grandes cantidades de datos al utilizar el sistema. 

2. Pruebe su procedimiento de captura de datos con tres compañeros de clase. Pídales 

retroalimentación acerca de la conveniencia del procedimiento de acuerdo con el tipo 
de usuarios que tendrá.el sistema. . . : 

3. Rediseñe los procedimientos de captura de datos para que tomen en cuenta las opinio¬ 
nes que recibió en el ejercicio de la pregunta anterior. Explique en un párrafo cómo se 
reflejan en sus cambios los comentarios recibidos. 


códigos como el código de cifrado también son útiles debido a que pueden ocultar la infor¬ 
mación que es sensible o se restringe al personal dentro del negocio. 

Revelar la información también es un uso importante de los códigos, debido a que pue¬ 
de permitir a los empleados del negocio localizar los artículos en el almacén y también puede 
hacer la entrada de datos más significativa. Los códigos de subconjunto de dígitos significati¬ 
vos usan subgrupos de dígitos para describir un producto. Los códigos mnemónicos también 
revelan la información al servir como ayuda de memoria para que un operador de entrada 
de datos pueda capturar los datos correctamente o ayuda al usuario final en el empleo de la 
información. El conjunto de caracteres Unicode incluye todos los símbolos del lenguaje 
estándar. Usted puede desplegar páginas Web escritas en otros alfabetos (griego, japonés, 
chino o hebreo, por ejemplo) usando un editor de método de entrada de Microsoft. Los 
códigos que son útiles para informar a computadoras o a las personas sobre qué funcio¬ 
nes desempeñar o qué acciones tomar se denominan códigos de función; dichos códigos 
evaden tener que deletrear con detalle qué acciones son necesarias. 

Otra parte de asegurar la entrada de los datos eficaz es la atención a los dispositivos de 
entrada usados. Un formulario eficaz y bien diseñado que sirve como un documento fuente 
es el primer paso. Pueden capturarse los datos a través de métodos diferentes, cada uno con 
la velocidad y confiabilidad propia. Se han rediseñado los teclados para que resulten más 
eficientes y se ha mejorado su ergonomía. El reconocimiento óptico de caracteres [OCR] 
permite la lectura de datos de entrada a través del uso de software especial que elimina al¬ 
gunos pasos y también requiere menos habilidades del empleado. 

Otros métodos de entrada de datos incluyen el reconocimiento de caracteres de tinta 
magnética (MICR) que usan los bancos para poner en código los números de cuenta de 
cliente y formularios de reconocimiento de marcas que se usan para altos volúmenes de entra¬ 
da de datos. Los códigos de barras (aplicados a productos o la identificación humana) también 
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aceleran la entrada de datos y mejoran su precisión y confiabilidad. Las nuevas tecnologías de 
la entrada como las cámaras digitales extienden la facilidad de uso y el rango de funciones 
disponible. Las terminales inteligentes, dispositivos de entrada [a menudo basados en mi¬ 
croprocesadores) con un monitor y teclado, que a veces pueden conectarse a una red de 
computadoras o al CPU, permiten capturar y completar transacciones en tiempo real. 

Junto con la codificación apropiada, la captura de datos y el uso de dispositivos de entra¬ 
da, la entrada de datos precisa puede reforzarse a través del uso de métodos de validación. El 
analista de sistemas debe asumir que ocurrirán errores en los datos y debe trabajar con los 
usuarios para diseñar pruebas de validación de datos para evitar que los datos erróneos se 
procesen y almacenen, porque los errores que no se descubren por largos periodos, son ca¬ 
ros y más difíciles de corregir. 

Las transacciones de entrada deben verificarse para asegurar que la transacción pedida 
sea aceptable, autorizada y correcta. Pueden validarse los datos de entrada a través de la in¬ 
clusión en el software de varios tipos de pruebas que verifican los datos perdidos, la longi¬ 
tud de los datos, rango y racionalidad, y valores inválidos para los datos. También pueden 
compararse los datos capturados con los datos guardados para propósitos de aprobación. Una 
vez que se capturan datos numéricos, éstos se pueden verificar y corregir automáticamente 
a través del uso de dígitos de verificación. 

Hay un orden fijo para las actividades de comprobación de datos. Hay también méto¬ 
dos de validación de patrones encontrados en el diseño de la base de datos o incluidos en 
lenguajes de programación. Los patrones se llaman expresiones regulares y contienen sím¬ 
bolos que representan el tipo de datos que deben estar presentes en un campo. 

Los ambientes de comercio electrónico ofrecen la oportunidad de una mayor precisión 
de datos. Los clientes pueden capturar sus propios datos, almacenarlos para su uso posterior, 
usan los datos guardados durante el proceso de surtido de la orden, y recibir retroalimenta- 
ción respecto a la confirmación de recepción de su orden y actualización de su estado. 

"PALABRAS y FRASES CLAVE 


administración de la cadena de 
abastecimiento 
cambiable 

característica de autocompletar 
codificación 
código de barras 
código de cifrado 
código de clasificación 
código de derivación alfabética 
código de función 
código de secuencia en bloque 
código de secuencia simple 
código de subconjunto de dígitos 
significativos 
código de validación 
código mnemónico 
cookies o galletas 
cuello de botella 
diferenciado 
dígito de verificación 


expresión regular 

formulario de reconocimiento de marcas 
prueba de comparación con los datos 
almacenados 

prueba de la clase o composición 
prueba de la longitud de campo correcta 
prueba de los datos perdidos 
prueba de los valores inválidos 
prueba de referencia cruzada 
prueba del rango o racionalidad 
reconocimiento de caracteres de tinta 
magnética (MICR) 

reconocimiento óptico de caracteres 
(OCR) 

redundancia en los datos de entrada 
tecleo 

terminal inteligente 
Unicode 

validación de entradas 


PREGUNTAS DE REPASO 

1. ¿Cuáles son los cuatro objetivos principales para la entrada de datos? 

2. Mencione los cinco propósitos generales para codificar datos. 

3. Defina el término código de secuencia simple. 
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4. ¿Cuándo es útil un código de derivación alfabética? 

5. Explique lo que se cumple con un código de clasificación. 

6. Defina el término código de secuencia en bloque. 

7. ¿Cuál es el tipo más simple de código para ocultar la información? 

8. ¿Cuáles son los beneficios de usar un código de subconjunto de dígitos significativos? 

9. ¿Cuál es el propósito de usar un código mnemónico para los datos? 

10. Defina el término código defunción. 

11. Mencione los ocho lincamientos generales para una codificación adecuada. 

12. ¿Cuáles son los datos cambiables? 

13. ¿Cuáles son los datos de diferenciación? 

14. ¿Cuál es una forma específica de reducir la redundancia de datos a ser capturados? 

15. Defina el término cuello de botella como se aplica a la entrada de datos. 

16. ¿Cuáles son las tres funciones repetitivas de entrada de datos que se pueden hacer más 
eficazmente por una computadora que por un operador de captura de datos? 

17. Mencione seis métodos de captura de datos. 

18. Mencione los tres problemas principales que pueden ocurrir con las transacciones de 
entrada. 

19. ¿Cuáles son las ocho pruebas para validar los datos de entrada? 

20. ¿Qué pruebas verifican si los campos de datos se completan correctamente con números 
o letras? 

21. ¿Qué prueba no permitiría a un usuario capturar una fecha como 32 de octubre? 

22. ¿Qué prueba asegura la precisión de los datos mediante la incorporación de un número 
en el código mismo? 

23. Mencione cuatro mejoras en la precisión de datos que pueden ofrecer las transacciones 
dirigidas a los sitios Web de comercio electrónico. 

24. ¿Qué es Unicode y cómo se usa? 

25. ¿Cuál es el proceso para validar datos capturados en los campos? 

26. ¿Qué es una expresión regular? 


PROBLEMAS 


1. Una universidad pequeña que se especializa en los programas de postgrado quiere llevar 
registro de cuando un estudiante particular realmente se inscribe. Sugiera un tipo de 
código para este propósito y dé un ejemplo de su uso en la universidad que demuestre su 
adecuación. 

2. El ejército ha usado un código de secuencia simple para llevar registro de nuevos reclutas. 
Sin embargo, ha habido algunos malentendidos entre los archivos del recluta debido a 
los números del recluta similares. 

a. En un párrafo, sugiera un esquema de codificación diferente que ayudará a identi- 
facar singularmente a cada recluta y explique cómo prevendrá el malentendido. 

b. El ejército está preocupado por que la información confidencial de su codifica¬ 
ción de nuevos reclutas (tal como el nivel de coeficiente intelectual, nivel de 
condición física al entrar al servicio) no se revele a empleados que no tienen el 
puesto adecuado, pero quiere que esta información se codifique en el número de 
identificación de un recluta para que aquellos que dirigen el entrenamiento básico 
estén inmediatamente conscientes del tipo de recluta que están entrenando. Su¬ 
giera un tipo de código (o combinación de códigos) que puedan lograr esta tarea 
y dé un ejemplo. 

3. Un código usado por una tienda de helados para pedir sus productos es 12DRM215- 
220. Este código se descifra de esta forma: 12 representa la cuenta de artículos en caja, 
DRM representa Dreamcicles (un tipo particular de helado) y 215-220 indica la clase 
entera de productos bajos en grasa manejados por el distribuidor. 

a. ¿Qué tipo de código se usa? Describa el propósito de cada parte (12, DRM, 215-220) 
del código. 
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b. Construya una entrada codificada que usa el mismo formato y lógica para un tipo 
de helado llamado Pigeon Bars, el cual viene en un paquete de seis y no es bajo en 
grasa. 

c. Construya una entrada codificada que use el mismo formato y lógica para una 
tipo de helado llamado Airwhips, el cual viene en un paquete de 24 y es bajo en 
grasa. 

4. Los operadores de entrada de datos en Michael Mulheren Construction han estado co¬ 
metiendo errores al introducir los códigos para productos de recubrimiento de paredes 
residenciales, los cuales son como sigue: U = estUcado, A = Aluminio, R = ladRillo, P = 
Panel de fibra, ES = ESmaltar el ladrillo con un color atrayente, E = parEd de madera 
natural, IN = pINtado flNal, AB = tablilla de contusión. Sólo se permite un código por 
dirección. 

a. Mencione los posibles problemas con el sistema de codificación que podrían 
contribuir a las entradas erróneas. [Sugerencia: ¿son las clases mutuamente exclu- 
yentes?) 

b. Diseñe un código mnemónico que ayudará a los operadores a entender lo que es¬ 
tán introduciendo y como consecuencia ayude a su exactitud. 

c. ¿Cómo rediseñaría las clases para los materiales de recubrimiento de paredes? Res¬ 
ponda en un párrafo. 

5. El siguiente es un código para un producto en una extensa línea de cosméticos: 
L02002Z621289. L significa que es un lápiz labial, 0 significa que se introdujo sin 
hacer coincidir un barniz de uñas, 2002 es un código de secuencia que indica en qué 
orden fue producido, Z es un código de clasificación que indica que el producto es hi- 
poalergénico y 621289 es el número de la planta (hay 15 plantas) donde se crea el 
producto. 

a. Critique el código mencionando las características que podrían llevar a la entrada 
de datos inexacta. 

b. El diseñador Brian d'Arcy James es dueño de la empresa cosmética que usa este 
esquema de codificación. Siempre interesado en un diseño nuevo, Brian está de¬ 
seoso de ver un código más elegante que codifique la misma información de una 
mejor forma. Rediseñe el esquema de codificación y proporcione una clave para 
su trabajo. 

c. Escriba una frase para cada cambio que ha sugerido, indicando qué problema de 
entrada de datos (del problema 5 a) eliminará el cambio. 

6. La empresa cosmética d'Arcy James necesita que su vendedor use una libreta de apun¬ 
tes para introducir pedidos de los grandes almacenes de menudeo (sus clientes más 
grandes). Esta información se envía entonces a los almacenes y los pedidos se envían en 
el orden en el que fueron recibidos. Desafortunadamente, los almacenes están cons¬ 
cientes de esta política y son sumamente competitivos sobre cuál ofrecerá primero 
nuevos productos a James d'Arcy. Muchos minoristas han tomado un camino vil y han 
persuadido al vendedor para falsificar sus fechas de pedido en los formularios de ventas 
registrándolas antes de lo que realmente son. 

a. Este problema está creando estragos en el almacén. Disciplinar al personal involucra¬ 
do no es factible. ¿Cómo puede usarse la computadora del almacén para certificar 
cuándo se hacen los pedidos realmente? Explique en un párrafo. 

b. Ixrs vendedores están quejándose que ellos tienen que ignorar su verdadero trabajo 
de vender para poder codificar los datos de cada orden. Liste los datos que deben 
guardarse en y deben recuperarse de la computadora central en lugar de codificarse 
y capturarse para cada orden. 

c. Describa en un párrafo o dos cómo el uso de un código de barras podría ayudar a 
resolver el problema en el problema 6b. 

7. Mencione el mejor método de entrada de datos y su razón para escogerlo para cada una 
de las cinco situaciones listadas a continuación: 

a. El recibo para una compañía de servicios públicos que permite la notificación de 
un cambio en la dirección del cliente al entregarse para pago. 
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b. Sólo se permite acceder a los datos si hay identificación positiva de la persona que 
los solicita. 

c. No hay suficiente personal entrenado disponible para interpretar las respuestas largas 
hechas por escrito a muchos formularios que se enviaron para capturar las respues¬ 
tas de un examen de opción múltiple; el requisito de confiabilidad es alto; la respuesta 
rápida no es una prioridad. 

d. El diseño del almacén para una tienda de descuento de discos compactos; los ana¬ 
queles se etiquetan con la información del precio, pero los discos individuales no 
lo son; y hay pocos operadores con experiencia disponibles para capturar los datos 
de precio. 

e. Un centro de atención para casos de envenenamianto que mantiene una base de 
datos grande de venenos y antídotos; necesita una manera de capturar los datos en 
el veneno tomado, así como el peso, edad y condición física general de la víctima 
cuando una persona llama al número gratuito del centro para pedir consejo y aten¬ 
der la emergencia. 

f. La compra en línea de un CD por un cliente con una tarjeta de crédito. 

8. Ben Coleman, uno de los miembros de su equipo de analistas de sistemas, le sorprende 
al afirmar que cuando un sistema usa una prueba para la longitud correcta del campo, 
es redundante incluir también una prueba de rango o racionalidad. En un párrafo, dé un 
ejemplo que demuestra a Ben que está equivocado. 

9. Varios minoristas han empezado a enviar una tarjeta de crédito estatal que sólo es vá¬ 
lida en las tiendas de su estado. Como una cortesía, se permite a los cajeros transcribir 
el número de cuenta de 15-dígito a mano (después de recibirlo de la oficina de conta¬ 
bilidad) si el cliente no lleva consigo la tarjeta. El único problema es que a veces se 
capturan números de cuenta erróneos en el sistema, produciendo facturas a cuentas 
inexistentes. 

a. ¿Qué clase de prueba de validez aclararía el problema? ¿Cómo? Responda en un 
párrafo. 

b. Sugiera un método de entrada de datos alternativo que podría eliminar este problema 
por completo. 

10. Los siguientes son números de parte: 

38902 

38933 

39402 

35693 

35405 

39204 


Desarrolle un dígito de verificación para los números listados que usen el multiplicador 
1-3-1-3-1 y módulo 11. Use el método presentado en este el capítulo. ¿Por qué algunos 
números tienen el mismo dígito de verificación? 

11. Desarrolle un sistema de dígito de verificación para los números del problema 10 que 
usen como multiplicador al 5-4-3-2-1 y módulo 11. 

12. ¿Por qué no habría un sistema de dígito de verificación con un multiplicador de l-l-l-l-l? 
¿Qué errores ignoraría? 

13. Defina una expresión regular para validar lo siguiente: 

a. Un código postal de Estados Unidos. El código postal debe tener cinco dígitos, 
seguidos por un guión optativo y cuatro dígitos. 

b. Un número del teléfono en el formato (el aaa) nnn-nnnn, dónde el aaa representa 
el código del área y los n's representan los dígitos. 

c. El código de la derivación alfabético ilustró en este el capítulo para un suscriptor 
de la revista. El formato es 99999XXX9999XXX, dónde X representa una letra y 
9 representan un número. 
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PROYECTO s DE GRUPO 

1. Junto con sus miembros de grupo, lea la Oportunidad de consultaría 15.3, "Capturar o 
no capturar: he ahí el dilema", presentada en este capítulo. Diseñe un sistema de entrada 
de datos apropiado para las Industrias de Elsinore. El plan de su grupo debe dar énfasis 
a eficacia y exactitud. Además, distinga entre datos que son cambiables y datos que di¬ 
ferencian un artículo a capturar de todos otros. Dibuje prototipos de cualquier pantalla 
necesaria para explicar lo que usted está recomendando. 

2. Divida su grupo en analistas y empleados de Elsinore Industries para jugar diferentes 
roles. Los analistas deben presentar el nuevo sistema de entrada de datos, incluyendo 
los prototipos de pantallas. Pida la retroalimentación del diseño de los empleados de 
Elsinore. 

3. Escriba un párrafo breve que describa cómo mejorar el plan de entrada de datos original 
basado en los comentarios recibidos. 
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El martes por la tarde Anna y Chip sostienen su reunión semanal de revisión del análisis 
y el diseño. Chip se dirige hacia una enorme pila de documentos que se encuentran perfec¬ 
tamente ordenados en una gran mesa. "No puedo creer que estemos a punto de terminar el 
diseño de este sistema", comenta. "Ha sido un largo proceso, pero apuesto a que hemos 
obtenido suficiente retroalimentación de los usuarios para garantizar un sistema de alta 
calidad. Todo lo que falta es el diseño de los procedimientos de entrada de datos y podremos 
enfocamos en las especificaciones para los programadores." 

"Sí", contesta Anna, "el final está a la vista. Empecemos por examinar el diseño corres¬ 
pondiente a la entrada del sistema". 

"El programa ADD SOFTWARE está en línea", apunta Chip. "El operador tendrá que 
comprobar visualmente cada transacción. Después de que todos los campos de datos se hayan 
editado para asegurar la exactitud, aparecerá un mensaje en la parte inferior de la pantalla. Es¬ 
te mensaje pedirá a los operadores que comparen los datos de la pantalla con el formulario 
para asegurar su exactitud y que hagan clic en el botón Save Record si son correctos. Los ope¬ 
radores tendrán la oportunidad de hacer cambios si los datos se introdujeron incorrectamente." 

Todos los campos de datos tendrán que editarse para asegurar que sean exactos. Chip 
observa: "A la larga, es mejor tener que realizar una edición completa para asegurar la exac¬ 
titud en los programas que enfrentarse al problema de que se almacenen datos erróneos en 
los archivos maestros y que se impriman en los informes". 

La estrategia para editar los campos es revisar los campos en el siguiente orden: 

1. La sintaxis —ya sea que los datos sean numéricos o alfabéticos— y la longitud de los 
datos. HARDWARE INVENTORY NUMBER es un ejemplo, que debe tener ocho 
caracteres de longitud y ser numérico. 

2. El contenido del campo, incluyendo el rango, el limite y los valores de los datos. Al vali¬ 
dar DATE PURCHASED, el mes debe ser de 1 a 12. Esta comprobación se debe realizar 
después de verificar que el mes sea numérico. 

3. Verificar la existencia de referencias cruzadas entre dos o más datos. Para revisar la 
parte del día de DATE PURCHASED, se utilizará una tabla del número de días posibles 
para cada mes en busca de un límite superior. Esta tabla no se podría usar si el número 
del mes no estuviera entre 1 y 12. Los dígitos de verificación constituyen otro ejemplo de 
una edición de referencias cruzadas. 

4. Ediciones externas, como leer un archivo para verificar si el registro que se va a agregar 
ya existe en el archivo. La lectura de registros es más lenta que la edición, la cual se 
realiza en la memoria principal, y sólo se debe llevar a cabo después de que los datos 
pasen con éxito todas las demás ediciones. 

Los criterios de edición se introdujeron en la pantalla Element Repository de Visible 
Analyst conforme los elementos se agregaron al diseño. Estos elementos incluyen criterios de 
edición sencillo y comprobación de tablas. El área Notes se podría utilizar para introducir crite¬ 
rios de edición. La entrada HARDWARE INVENTORY NUMBER incluye una referencia para 
utilizar el método módulo-11 para comprobar la parte del dígito de verificación del número. 
Además, al agregar una nueva computadora se debe leer el COMPUTER MASTER para ase¬ 
gurarse de que no exista un registro con el mismo HARDWARE INVENTORY NUMBER. 

"Creo que algunos informes serán útiles", le dice Chip a Anna. "El primer informe tiene 
que ver con la creación de una lista final de todos los elementos que se encuentren tanto en 
el COMPUTER MASTER como en los registros estructurales contenidos en el archivo 
maestro. El informe se produce con la característica Report, y muestra los elementos, su 
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Tabla de edición COMPUTER MASTER. 


longitud, imágenes y criterios de edición en el área Notes." Este informe se utiliza para crear 
la tabla de criterios de edición, que pasa a formar parte de las especificaciones del progra¬ 
ma. La tabla se muestra en la figura E15.1. 

Varios de los elementos tienen áreas Notes que se refieren a las tablas, así como entradas 
para los códigos en el área Valúes and Meanings. El elemento INTERNAL BOARD es un 
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ejemplo. "Elaboraré una lista de todas las tablas que necesitaremos", ofrece Anna. En esta 
ocasión se utiliza la característica Report Query para producir la información necesaria. Se 
imprime una lista de todos los elementos que contienen notas, empezando con "Table of 
codes". En la lista se incluyen Picture y Length, mostrando la sintaxis del código. Con esta 
lista se crean las tablas. 

Cada tabla de códigos se define utilizando tablas de Microsoft Access. Tanto Chip como 
Anna pasan tiempo trabajando en las tablas. Se elige un código mnemónico para BOARD y 
DISPLAY, porque para el personal de mantenimiento será fácil trabajar con ellos. Los códi¬ 
gos mnemónicos también se emplean para representar SOFTWARE CATEGORY, porque 
para los usuarios será fácil recordarlos. 

"Hay una amplia variedad de impresoras disponibles", comenta Chip. "Creo que aquí 
sería más conveniente un esquema de codificación de subconjunto de dígitos significativos. 
El primer dígito representa el tipo de impresora... láser, etc. Los dos dígitos siguientes son 
para el fabricante y los dos últimos constituyen un número secuencial que representa di¬ 
ferentes números de modelo." 

Anna está de acuerdo. "Es una buena idea. Chip. También podemos usar esta estrategia 
para las instalaciones del campus: el primer dígito para la ubicación del campus y los dos 
dígitos restantes para representar los edificios individuales del campus." 

Chip diseña los códigos para la tabla BOARD. La pantalla de Microsoft Access se 
muestra en la figura E15.2. Se utilizan dos columnas para definir códigos. La columna de 
la izquierda contiene el código y la de la derecha el significado del mismo. Estas entradas 
podrían modificarse y agregar nuevas entradas, con lo cual se daría flexibilidad al sistema 
final. 

"Aquí está la tabla SOFTWARE CATEGORY que elaboré", dice Anna. "Esta tabla se 
podría actualizar con facilidad cuando la universidad desarrolle o compre nuevo software." 
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"Éste es un valioso componente del sistema", comenta Chip. "Da consistencia a todos 
los códigos y sus significados." 

Chip y Anna terminan su trabajo mañana alrededor de las 11:30. Pasean por la sala felices, 
examinando una y otra vez el diseño final. Los meses de análisis, trabajo de diseño, consultas a 
los usuarios y cuidadosa observancia de los estándares por fin terminaron. 

"Me siento realmente bien por este proyecto", dice Anna. 

Chip asiente: "Estoy orgulloso de la calidad que conseguimos". 

EJERCICIOS 

\L$ E-l. Modifique e imprima los siguientes elementos con criterios de edición en el área Notes 
(o en Valúes and Meanings para códigos específicos). 

Element Edit Gritería 

Table of codes: Software 
Category Code 

B - Beginning; I - Intermedíate; 

A - Advanced 

0 - No Internet; M - Modem; 

1 - TI Line; W - Wireless 
Y - Yes; N - No 
M - Macintosh; 

9 - Windows 95; 

8 - Windows 98; 

N - Windows NT; 

X - Windows XT; 

0 - Windows 2000; 

E - Millennium; 

U-Unix 

E-2. Modifique e imprima los siguientes elementos con criterios de edición colocados en el 
área Notes: 

a. Elemento: SOFTWARE INVENTORY NUMBER 

Notes: Un dígito de verificación módulo 11 debe verificarse al introducir 

el número. El programa ADD SOFTWARE crea el dígito de verifi¬ 
cación. 

El programa ADD SOFTWARE también debe revisar el archivo 
SOFTWARE MASTER para asegurarse de que no exista un registro 
con el mismo número de inventario. 

b. Elemento: DATE PURCHASED 

Notes: Verifique que DATE PURCHASED sea menor o igual que la fecha 

actual. 

c. Elemento: QUANTITY RECEIVED 

Notes: Verifique que QUANTITY RECEIVED sea menor o igual que 

QUANTITY ORDERED. 



a. SOFTWARE CATEGORY 

b. COURSE TRAINING 

LEVEL CODE 

c. NETWORK 

CONNECTION ÑAME 

d. ZIP DRIVE CONNECTED 

e. OPERATING SYSTEM 



iggl Los ejercidos precedidos por un ¡cono Web indican que en el sitio Web del libro hay material de valor 
agregado. Los estudiantes pueden descargar una base de datos de Microsoft Access que pueden utilizar 
para completar los ejercicios. 
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d. Elemento: 
Notes: 

e. Elemento: 
Notes: 


SOFTWARE UPGRADE VERSION 

Asegúrese de que la UPGRADE VERSION del software sea menor 
que la versión actual. 

HARD DRIVE 
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Notes: HARD DRIVE 2 sólo procedería si ya existe una versión para 

HARD DRIVE 1. 

E-3. Vea e imprima el Coded Elements Report Query. 

E-4. Utilice Microsoft Access para ver la tabla SOFTWARE CATEGORY CODES. ¿Qué 
error hay en el diseño de estos códigos? 

E-5. Utilice Microsoft Access para modificar e imprimir la tabla BOARD CODES. Agregue 
los siguientes códigos. 

PCM PCMCIA Fax Modem 

WNT Wireless NetWork Card 

FER Finger print Reader Card 

E-6. Modifique e imprima con Microsoft Access la tabla PRINTER CODES. El formato de 
este código de subconjunto de dígitos significativos es el siguiente: 

TMMSS, donde 

T es el tipo de impresora 

M es el fabricante 

S representa un número secuencial, donde el número más grande indica un 

modelo mejorado 

Los valores para el tipo de impresora son: 

0 Multifunction 

1 Photo 

2 Inkjet 

3 Thermal 

4 Láser 

5 PostScript 

6 Plotter 

Los valores del fabricante son los siguientes; 

01 IBM 

02 Epson 

03 Hewlett-Packard 

04 Panasonic 

05 Star Micronics 

06 Samsung 

07 Canon 

08 Texas Instruments 

Agregue los siguientes códigos: 

Código Significado 

20301 Hewlett-Packard DeskJet 6122 

50601 ML-1710 Láser Printer 

00201 Epson Stylus Multifunction 

40305 Hewlett-Packard LaserJet 1360 

40107 Panasonic i950 Photo Printer 
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E-7. Utilice Microsoft Access para modificar e imprimir, con el formato mnemónico, la 
tabla MONITOR CODES. Agregue las siguientes entradas: 

Código Significado 

LCDM LCD 

FSCM Fiat Screen 

XGAT XGATFTScreen 

SVGA SuperVGA 

PLSM Plasma 

AMTX Active Color Matrix 

E-8. Después de conversar con Dot Matricks y Mike Crowe, se acordó que los códigos del 
campus deben ser ordenables para instalar hardware y software, así como para crear 
hojas de inventario. Modifique e imprima con Microsoft Access la tabla CAMPUS 
LOCATION CODES. El primer dígito representa la ubicación del campus. Los valo¬ 
res son los siguientes: 

1 Central Campus 

2 Waterford Campus 

3 Hillside Campus 

Los tres dígitos siguientes representan edificios del campus, con los siguientes códigos: 

001 Administration 010 Environmental Studies 

002 Admissions 011 Geology 

003 Agricultural 012 Law 

004 Astronomy 013 Library 

005 Business 014 Mathematics 

006 Chemical Engineering 015 Medicine 

007 Computer Science 016 Physics 

008 Education 017 Psychology 

009 Engineering 018 Zoology 

Utilice una combinación (que usted elija) de códigos de campus y edificio para elaborar 
la tabla de códigos final. Incluya el significado del código. 















ASEGURAMIENTO DE LA 
CALIDAD MEDIANTE 
INGENIERIA DE SOFTWARE 
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OBJETIVOS DE APRENDIZAJE 

Una vez que haya dominado el material de este capítulo, podrá: 

1. Reconocer la Importancia de adoptar un enfoque de calidad total para todo el SDLC. 

2. Crear diagramas de estructura para diseñar sistemas modulares con un enfoque descendente 
(de arriba a abajo). : ! v t :í\;£ 

3. Usar diversas técnicas para mejorar la calidad del diseño y mantenimiento del software. 

4. Entender la Importancia de ejecutar una variedad de pruebas durante el desarrollo de sistemas 
para Identificar problemas desconocidos. 


La calidad ha sido durante mucho tiempo una preocupación para las empresas, como.lo debe 
ser para los analistas dé sistemas en el análisis y diseño de sistemas de información. Es de¬ 
masiado arriesgado emprender todo el proceso de análisis y diseño sin usar un enfoque 
de aseguramiento de la calidad. Los tres enfoques para el aseguramiento de la calidad 
mediante ingeniería de software son: (1) garantizar el aseguramiento de la calidad total 
diseñando sistemas y software con un enfoque modular, descendente [de arriba a abajo); 
[2) documentare! software con las herramientas adecuadas, y [3) probar, mantener y audi¬ 
tar el software.: ■ 

Dos propósitos guían el aseguramiento de la calidad. El primero es que el usuario del 
sistema de información es el factor individual más importante en establecer y evaluar su 
calidad. El segundo es que es mucho menos costoso corregir los problemas en sus fases ini¬ 
ciales que esperar hasta que un problema se manifieste a través de las quejas o crisis del 
usuario. ■' : ;v- í .:V-'• 

Ya hemos aprendido acerca* de la enorme inversión de mano de obra y otros recursos 
empresariales qué se réquierén para desarrollar cotí éxito un sistema. El uso del asegura¬ 
miento dé lá calidad a lo largo del proceso es una forma de reducir los riesgos, ayuda a ga- 
rantizar que el sistema resultante será lo qué se necesita y desea, y mejorará: notablemente^ 
algún aspecto del desempeño dél negocio. Este capítulo proporciona al analista tres enfo¬ 
ques jjnncipales para la cahdad. . , 


ENFOQUE DE ADMINISTRACION DE LA CALIDAD TOTAL a 

La administración :de la calidad total [TQM, por sus siglas cii inglés) es. esencial á lo largo de 
todos los-pasos del desarrollo de sistemas. Según Dean y Evans [ 1-994), Tós principales ele¬ 
mentos dé la'TQM.sóló son significativos cuando se presentan en un contexto organizácip-j 





























nal que favorece un esfuerzo integral por la calidad. Es en este contexto donde los elemen¬ 
tos de enfoque en el cliente, planificación estratégica y liderazgo, mejora continua, facultar 
al empleado y trabajo en equipo se unifican con el propósito de cambiar el comportamien¬ 
to de los empleados y, en consecuencia, el curso de la organización. Observe que el concepto 
de calidad se ha ampliado con el paso de los años para reflejar un enfoque en toda la orga¬ 
nización, y no tan sólo en la producción. En lugar de concebir a la calidad como un control 
del número de artículos defectuosos que se producen, ahora se considera como un proceso 
evolutivo hacia la perfección que se denomina administración de la calidad total. 

Los analistas de sistemas deben estar conscientes de los factores que despiertan el inte¬ 
rés en la calidad. Es importante comprender que el creciente compromiso de las empresas 
hacia la TQM encaja sumamente bien en los objetivos generales del análisis y diseño de sis¬ 
temas. 

SEISSEGMA 

La llegada de Seis Sigma ha cambiado el enfoque de la administración de la calidad. Cada 
analista de sistemas necesita estar consciente de Seis Sigma y aplicar algunos de los princi¬ 
pios a sus proyectos de análisis de sistemas. Originalmente desarrollado por Motorola en la 
década de 1980, Seis Sigma es más que una metodología; es una cultura basada en la cali¬ 
dad. La meta de Seis Sigma es eliminar todos los defectos. Esto se aplica a cualquier produc¬ 
to, servicio o proceso. En los libros de texto de administración de operaciones que se publi¬ 
caron a partir de la década de 1970 y hasta fines del siglo pasado, el control de calidad se 
expresó en términos de tres desviaciones estándar de la media, o tres sigma, lo cual es equi¬ 
valente a aproximadamente 67,000 defectos por millón de oportunidades. Seis Sigma im¬ 
plica una meta de sólo 3.4 defectos por millón de oportunidades. 

Seis Sigma es un enfoque descendente de arriba a abajo. Se requiere que un CEO adop¬ 
te la filosofía y un ejecutivo funja como campeón de proyecto. Un líder de proyecto de Seis 
Sigma se denomina Black Bell (cinta negra]. Las personas escogidas para ser Black Belts pue¬ 
den provenir de diferentes niveles e incluso diferentes niveles salariales, pero deben tener 
experiencia en el proyecto y contar con capacitación especial. Los Black Belts se certifican 
después que han liderado proyectos de manera exitosa. Los miembros del proyecto se deno¬ 
minan Green Belts (cintas verdes). Los Black Belts maestros son los Black Belts que han tra¬ 
bajado en muchos proyectos y están disponibles como un recurso para los equipos de pro¬ 
yectos. (La metáfora de Black Belt viene del sistema de clasificación de capacidades en las 
artes marciales. Resalta la importancia de la disciplina en todos los ámbitos.] 

Seis Sigma se puede resumir como una metodología. En la figura 16.1 se muestran los 
pasos de Seis Sigma. Sin embargo. Seis Sigma es mucho más que una metodología; es una fi¬ 
losofía y una cultura. 

Para más información sobre Seis Sigma y administración de la calidad, visite el sitio 
Web del Juran Center en la Carlson School of Management de la University of Minnesota 
en Twin Cities (www.csom.umn.edu). En 2002 el Juran Center emitió un manifiesto para 
apoyar y fomentar la calidad. Los autores de este libro firmaron el manifiesto en ese mo¬ 
mento y sinceramente estamos de acuerdo con sus principios. 

Joseph M. Juran dijo: "Toda mejora de la calidad ocurre proyecto tras proyecto y de 
ninguna otra forma" (Juran, 1964). Ixts analistas de sistemas y gerentes de proyecto deben 
tomar muy en serio esta afirmación. 


RESPONSABILIDAD DE LA ADMINISTRACIÓN DE LA CALIDAD TOTAL 

En términos prácticos, gran parte de la responsabilidad por la calidad de los sistemas de in¬ 
formación recae en los usuarios de éstos y en los directivos. Para que la TQM se vuelva una 
realidad en los proyectos de sistemas, deben darse dos condiciones. Primera, debe existir un 
apoyo organizacional incondicional por parte de los directivos, lo cual es distinto a simple¬ 
mente respaldar el nuevo proyecto de los directivos. Este apoyo significa establecer un con- 
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texto para que los directivos consideren seriamente cómo afecta su trabajo la calidad de los 
sistemas de información y la información misma. 

Es necesario que tanto el analista como la empresa se comprometan desde el principio 
con la calidad para lograr la meta de calidad. Este compromiso da como resultado un es¬ 
fuerzo uniformemente controlado hacia la calidad durante todo el ciclo de vida del desarro¬ 
llo de sistemas, y está en marcado contraste con tener que dedicar gran cantidad de esfuerzo 
para resolver problemas al final del proyecto. 

El apoyo organizacional para conseguir calidad en sistemas de información de adminis¬ 
tración se puede lograr al proporcionar tiempo en el trabajo para los círculos de calidad de 
SI, los cuales consisten de seis a ocho pares organizacionales específicamente responsables 
de considerar cómo mejorar los sistemas de información y cómo implementar las mejoras. 

Mediante el trabajo en los círculos de calidad de SI o a través de otros mecanismos ya 
colocados, la administración y usuarios deben desarrollar lincamientos para los estándares 
de calidad de sistemas de información. Preferentemente, los estándares se rediseñarán cada 
vez que un nuevo sistema o una modificación mayor se proponen formalmente por el equi¬ 
po de análisis de sistemas. 

No es fácil crear los estándares de calidad, pero es posible y se ha hecho. Parte del tra¬ 
bajo del analista de sistemas es alentar a usuarios a que cristalicen sus expectativas acerca de. 
los sistemas de información y sus interacciones con éstos. 

Los estándares de calidad departamentales se deben comunicar mediante retroalimen- 
tación para el equipo de análisis de sistemas. Normalmente el equipo está sorprendido por 
lo que se ha desarrollado. Las expectativas generalmente son menos complejas de lo que 
analistas experimentados saben se podría hacer con un sistema. Además, los problemas hu¬ 
manos que se han omitido o menospreciado por el equipo del analista se podrían diseñar 
como extremadamente urgentes en los estándares de calidad que fijen los usuarios. Involu¬ 
crar a los usuarios en explicar los estándares de calidad para los sistemas de información 
ayudarán al analista a evitar errores costosos en el desarrollo de sistemas no deseados o in¬ 
necesarios. 
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Formulario para documentar 
repasos estructurados; los repasos 
se pueden hacer siempre que se 
finalice una parte de la 
codificación, de un sistema o de 
un subsistema. 


Utilice los repasos estructurados para obtener (y después emprender acciones acordes 
con] retroalimentación valiosa desde una perspectiva que le falte. Al igual que con todas las 
medidas de aseguramiento de la calidad, el propósito de los repasos es evaluar el producto 
sistemáticamente de manera continua en lugar de esperar hasta la terminación del sistema. 

DISEÑO Y DESARROLLO DE SISTEMAS 

En esta sección definimos los diseños de sistemas ascendente (de abajo a arriba o bottom-up) 
y descendente (de arriba abajo o top-down), así como también el enfoque modular para la 
programación. Discutimos las ventajas de cada uno, así como también las precauciones que- 
se deben observar al emplear un enfoque descendente o uno modular. También discutimos 
las propiedades de los enfoques descendente y modular para ayudar en el aseguramiento 
de la calidad de los proyectos de sistemas. 
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Diseño ascendente Este diseño se refiere a identificar los procesos que necesitan compu- 
tarizarse conforme surgen, analizarlos como sistemas y codificar los procesos o comprar 
software empaquetado para resolver el problema inmediato. Los problemas que requieren 
computarizarse normalmente se encuentran en el nivel más bajo de la organización. Con 
frecuencia este tipo de problemas son estructurados y por lo tanto son más sensibles a la 
computarización; también son los más rentables. Por lo tanto, el nombre ascendente se refiere 
al nivel inferior en el cual se introduce primero la computarización. Por ejemplo, con fre¬ 
cuencia los negocios toman este enfoque para el desarrollo de sistemas al adquirir software 
comercial para la contabilidad, un paquete diferente para la programación de producción y 
otro para el marketing. 

Cuando la programación interna se hace con un enfoque de ascendente, es difícil in¬ 
terconectar los subsistemas de manera que se desempeñen fácilmente como un sistema. 
Es muy costoso corregir las fallas de la interconexión y muchas de ellas no se descubren 
sino hasta que se completa la programación, cuando los analistas intentan reunir el siste¬ 
ma en la fecha límite señalada para la entrega. En esta situación, hay poco tiempo, presu¬ 
puesto o paciencia del usuario para la depuración de interconexiones delicadas que se han 
ignorado. 

Aunque cada subsistema aparenta conseguir lo que quiere, al considerar el sistema glo¬ 
bal hay serias limitantes para tomar un enfoque de ascendente. Una es que hay duplicidad 
de esfuerzo en comprar software e incluso en introducir los datos. Otra es que se introdu¬ 
cen datos inválidos en el sistema. Una tercera, y quizás la desventaja más seria del enfoque 
ascendente, es que no se consideran los objetivos organizacionales globales, y por lo tanto 
dichos objetivos no se pueden cumplir. 

Diseño descendente Es fácil visualizar este enfoque; como se muestra en la figura 16.3, 
significa ver una descripción amplia del sistema y después dividirla en partes más pequeñas 
o subsistemas. El diseño descendente permite a los analistas de sistemas determinar prime¬ 
ro los objetivos organizacionales globales, así como también determinar cómo se reúnen 
mejor en un sistema global. Después el analista divide dicho sistema en subsistemas y sus 
requerimientos. 

El diseño descendente es compatible con el pensamiento general de sistemas que se 
discutió en el capítulo 2. Cuando los analistas de sistemas utilizan un enfoque descendente. 


Uso de un enfoque descendente 
para determinar primero los 
objetivos organizacionales 
generales. 
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están pensando en la manera en que las interrelaciones e interdependencias de subsistemas 
se adaptan a la organización existente. El enfoque descendente también proporciona el én¬ 
fasis deseable en la colaboración o interconexiones que los sistemas y sus subsistemas nece¬ 
sitan, el cual falta en el enfoque ascendente. 

Las ventajas de usar un enfoque descendente para el diseño de sistemas incluyen evitar 
el caos de intentar diseñar un sistema de repente. Como hemos visto, planear e inrplemen- 
tar sistemas de información de administración es increíblemente complejo. Intentar colocar 
todos los subsistemas en su lugar y ejecutarlos en seguida es casi un fracaso seguro. 

Una segunda ventaja de tomar un enfoque descendente para diseñar es que permite 
separar a los equipos de análisis de sistemas para trabajar en paralelo en diferentes subsiste¬ 
mas, lo cual puede ahorrar mucho tiempo. El uso de equipos para el diseño de subsistemas 
se ajusta particularmente bien a un enfoque de control de calidad total. 

Una tercera ventaja es que un enfoque descendente evita un problema mayor asociado 
con un enfoque ascendente; evita que los analistas de sistemas se metan tanto en los deta¬ 
lles que pierdan de vista lo que se supone que el sistema hace. 

Hay algunas dificultades con el diseño descendente que el analista de sistemas necesita 
saber. La primera es el riesgo de que el sistema se divida en subsistemas "erróneos". Se debe 
poner atención a las necesidades que se traslapen y a la compartición de recursos de mane¬ 
ra que la partición en subsistemas tenga sentido para todos los sistemas. Además, es impor¬ 
tante que cada subsistema solucione el problema correcto. 

Un segundo riesgo es que una vez que se hacen las divisiones de un subsistema, sus in¬ 
terfaces se podrían descuidar o ignorar. Es necesario detallar de quién es la responsabilidad 
de las interfaces. 

Una tercera advertencia que acompaña al uso de un diseño descendente es que los sub¬ 
sistemas se deben reintegrar eventualmente. Los mecanismos para la reintegración se ne¬ 
cesitan poner en funcionamiento desde el principio. Una sugerencia es negociar informa¬ 
ción regular entre los equipos del subsistema; otra es usar herramientas que permiten 
flexibilidad si se requieren cambios para los subsistemas interrelacionados. 

La administración de la calidad total y el enfoque descendente para diseñar pueden 
estar relacionados. El enfoque descendente proporciona el grupo de sistemas con una di¬ 
visión más natural de usuarios en grupos de trabajo para subsistemas. Los grupos de tra¬ 
bajo establecidos de esta forma después pueden servir a una función dual como círculos 
de calidad para el sistema de información de administración. La estructura necesaria para 
el control de calidad está en el lugar, así como la motivación apropiada para obtener el 
subsistema para lograr las metas departamentales que son importante para los usuarios in¬ 
volucrados. 


DESARROLLO MODULAR 


Una vez que se toma el enfoque del diseño descendente, el enfoque modular es útil en la 
programación. Este enfoque implica dividir la programación en partes lógicas y manejables 
llamadas módulos. Este tipo de programación funciona bien con el diseño descendente por¬ 
que da énfasis a las interfaces entre los módulos y no los descuida hasta el final del desarro¬ 
llo de sistemas. Idealmente, cada módulo individual debe ser funcionalmente cohesivo de 
manera que se encargue de realizar una sola función. 

El diseño de programa modular tiene tres ventajas principales. Primero, los módulos 
son más fáciles de escribir y de depurar porque prácticamente son independientes. Rastrear 
un error en un módulo es menos complicado, debido a que un problema en un módulo no 
debe causar problemas en otros. 

Una segunda ventaja del diseño modular es que los módulos son más fáciles de mante¬ 
ner. Normalmente las modificaciones se limitarán a unos módulos y no seguirán en todo el 
programa. 

Una tercer ventaja del diseño modular es que los módulos son más fáciles de entender, 
debido a que son subsistemas independientes. Por lo tanto, un lector puede adquirir una lis¬ 
ta del código de un módulo y entender su función. 
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Algunos lincamientos para la programación modular incluyen lo siguiente: 

1. Mantener cada módulo de un tamaño manejable (incluir a la perfección una sola 
función). 

2. Poner particular atención a las interfaces críticas (los datos y variables de control que se 
pasan a otros módulos]. 

3. Minimizar el número de módulos que el usuario debe modificar al hacer los cambios. 

4. Mantener las relaciones jerárquicas establecidas en las fases descendentes. 

MODULARIDAD EN EL ENTORNO DE WINDOWS 

La modularidad se está volviendo muy importante. Microsoft desarrolló dos sistemas para 
vincular los programas en su entorno de Windows. El primero se llama intercambio dinámi¬ 
co de datos (DDE], el cual comparte código al usar archivos de biblioteca de vínculos diná¬ 
micos (DLL). Al usar DDE, un usuario puede almacenar datos en un programa —quizás en 
una hoja de cálculo tal como Excel— y después usar dichos datos en otro programa, por de¬ 
cir, en un paquete de procesamiento de texto tal como Word para Windows. El programa 
que contiene los datos originales se denomina servidor y el programa que los usa se denomi¬ 
na cliente. El vínculo de DDE se puede establecer de manera que cuando se abra el archivo 
de procesamiento de texto del cliente, los datos se actualicen automáticamente y se reflejen 
los cambios hechos en el archivo de hoja de cálculo del servidor desde la última vez que se 
abrió dicho archivo de procesamiento de texto. (Véase el capítulo 17 para una discusión 
amplia del modelo cliente/servidor.) 

Uno de los archivos de la DLL normalmente usados es COMMDLG.DLL, el cual con¬ 
tiene los cuadros de diálogo de Windows para Abrir Archivos, Guardar Archivos, Buscar e 
Imprimir. Una ventaja de usar este archivo es que los programas tendrán la misma aparien¬ 
cia y funcionamiento que otros programas de Windows. También acelera el desarrollo, debi¬ 
do a que los programadores no tienen que escribir el código contenido en los archivos DLL 
más comunes. 

Un segundo enfoque para vincular programas en Windows se denomina vinculación e 
incrustación de objetos (OLE). Este método de vincular programas es superior a DDE 
porque está ligado a los datos y gráficos de la aplicación. Mientras que DDE utiliza un en¬ 
foque de cortar y pegar para vincular datos y no retiene el formato, OLE retiene todas las 
propiedades de los datos creados originalmente. Este enfoque orientado a objetos (véase el 
capítulo 18 para una discusión de principios orientados a objetos) permite al usuario final 
permanecer en la aplicación del cliente y editar los datos originales en la aplicación del ser¬ 
vidor. Con OLE, cuando un usuario final hace clic en el objeto incrustado, se despliega una 
barra de herramientas que permite la edición visual. 


USO D E DIAG RAMAS DE ESTRUCTU RA PARA DISE ÑAR SISTEMAS 


La herramienta recomendada para diseñar un sistema modular descendente se denomina 
diagrama de estructura. Este gráfico simplemente es un diagrama que consiste de cuadros 
rectangulares, los cuales representan los módulos, y de flechas de conexión. 

La figura 16.4 muestra tres módulos que se etiquetan como 000,100 y 200 y se conec¬ 
tan mediante líneas de ángulo recto. Los módulos de nivel superior se numeran por lOOs o 
l,000s y los módulos de nivel inferior se numeran por lOs o lOOs. Esta enumeración per¬ 
mite a programadores insertar módulos que usan un número entre los números de módulo 
adyacentes. Por ejemplo, un módulo insertado entre los módulos 110 y 120 recibiría el nú¬ 
mero 115. Si se insertaran dos módulos, los números podrían ser 114 y 117. Estos esquemas 
de numeración varían, dependiendo de los estándares organizacionales usados. 

A los lados de las líneas de conexión, se dibujan dos tipos de flechas. Las flechas con los 
círculos vacíos se denominan parejas de datos y las flechas con los círculos rellenados se de¬ 
nominan banderas de control o interruptores. Un interruptor es lo mismo que una bandera 
de control excepto por que está limitado por dos valores: sí o no. Estas flechas indican que 
algo se pasa hacia abajo al módulo inferior o hacia arriba al superior. 
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Un diagrama de estructura 
favorece el diseño descendente 
mediante'módulos;;,::' 


El analista debe mantener a la perfección este acoplamiento al mínimo. Cuando hay 
pocas parejas de datos y banderas de control en el sistema, lo más fácil es cambiar el siste¬ 
ma. Cuando finalmente se programan estos módulos, es importante pasar el menor número 
de parejas de datos entre los módulos. 

Aún más importante es que se deben evitar las banderas de control numerosas. El con¬ 
trol se diseña para ser pasado de los módulos de nivel inferior a los de nivel superior en la 
estructura. Sin embargo, en raras ocasiones será necesario pasar el control hacia abajo en 
la estructura. Las banderas de control deciden qué parte de un módulo se ejecuta y están 
asociadas con las instrucciones IR..THEN...ELSE... y otros tipos similares de instruccio¬ 
nes. Cuando el control se pasa en forma descendente, se permite que un módulo de nivel 
inferior tome una decisión y el resultado es un módulo que desempeña dos tareas diferen¬ 
tes. Este resultado rompe con el modelo de un módulo funcional: un módulo sólo debe 
desempeñar una tarea. 

La figura 16.5 ilustra una parte de un diagrama de estructura para agregar nuevos em¬ 
pleados. El programa lee un archivo de TRANSACCIÓN DE EMPLEADO y verifica que 
cada registro en el archivo únicamente contenga datos aceptables. Los informes se impri¬ 
men por separado para los registros válidos e inválidos, proporcionando un rastro para audi¬ 
toría de todas las transacciones. El informe que contiene los registros inválidos se envía al 



Eslc diagrama do estructura 
muestra el control que se mueve 
de forma descendente y también 
muestra los módulos no 
funcionales. 
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FIGURA 


El pseudocódigo para el módulo 
230 ¡lustra el efecto de pasar de 
forma descendente un Interruptor. 
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usuario para la corrección de errores. Los registros que son válidos se ponen en un archi¬ 
vo de transacción válido, el cual se pasa a un programa separado para actualizar el archivo 
MAESTRO DE EMPLEADOS. El módulo 200, AGREGAR NUEVO REGISTRO DEL 
EMPLEADO, representa la lógica de agregar un registro. Debido a que el módulo 230 se 
usa para imprimir ambos informes, se debe enviar una bandera de control hacia abajo para 
indicar al módulo que informe imprimir. De esta manera la lógica del módulo 230 se con¬ 
trola por completo mediante una instrucción IF, la cual se ilustra en la figura 16.6. 

La figura 16.7 muestra la forma correcta de diseñar la estructura por debajo del módu¬ 
lo 200, AGREGAR NUEVO REGISTRO DEL EMPLEADO. Aquí, cada función de impre- 
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sión se ha puesto en un módulo separado y las banderas de control sólo se pasan a la estruc¬ 
tura al módulo de nivel superior. 

También se deben examinar los datos que se pasan a través de las parejas de datos. Es 
mejor pasar sólo los datos requeridos para realizar la función del módulo. Este enfoque se 
denomina acoplamiento de datos. El paso excesivo de datos se denomina acoplamiento de 
sello, y aunque es relativamente inofensivo, reduce la posibilidad de crear un módulo reu- 
tilizable. 

La figura 16.8 ilustra este concepto. Aquí, el módulo EDITAR NUEVO CLIENTE pa¬ 
sa el REGISTRO DEL CLIENTE al módulo EDITAR NUMERO TELEFÓNICO DEL 
CLIENTE, donde NÚMERO TELEFÓNICO, un elemento encontrado en el REGISTRÓ 
DEL CLIENTE, se valida, y una bandera de control se pasa atrás al módulo EDITAR 
NUEVO CLIENTE. El TIPO DE ERROR (si hay alguno), uno que contiene un mensaje 
de error tal como "CÓDIGO DE ÁREA INVALIDÓ” o el "NUMERÓ TELEFÓNICO 
NO ES NUMÉRICO", también se pasa hacia arriba. El mensaje se podría imprimir o des¬ 
plegar en pantalla. 

Aunque dichos módulos son bastante fáciles de crear y modificar cada vez que es nece¬ 
sario editar un número telefónico de un registro fuente diferente, se debe crear un nuevo 
módulo, similar al EDITAR NUMERO TELEFÓNICO DEL CLIENTE. Además, si la forma 
del número telefónico está validando los cambios, como ocurre cuando se debe agregar un 
nuevo código de área o un código de país internacional, cada uno de estos módulos de nivel 
inferior se debe modificar. 

Debido a que el módulo de nivel inferior no requiere ninguno de los otros elementos 
en el REGISTRO DEL CLIENTE, la solución es pasar sólo el NÚMERO TELEFÓNICO al 
módulo de nivel inferior. El nombre del módulo en este escenario cambia a EDITAR NÚ- 
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Como se muestra en la figura 16.9, el bucle es otro símbolo usado en los diagramas de 
estructura. Este símbolo indica que algunos procedimientos encontrados en los módulos 
100 y 200 serán repetidos hasta terminar. Este ejemplo implica que LEER REGISTRO 
DEL CLIENTE y EDITAR REGISTRO DEL CLIENTE se repitan hasta que todos los 
registros del cliente se completen. Después se clasifican en el módulo 300, pero como 
puede ver, se pueden clasificar de tres formas diferentes: por nombre, código postal o códi¬ 
go de área. Para mostrar que parte, pero no toda, de la clasificación se realizará, se usa otro 
símbolo, un diamante. Observe que el diamante no indica cuál de los tres módulos se de¬ 
sempeñará, ni el bucle indica qué módulos se repetirán. Estos símbolos pretenden delibera¬ 
damente ser generales, no específicos. 


DIBUJO DE UN DIAGRAMA DE ESTRUCTURA 

Obviamente, los diagramas de estructura se deben dibujar de arriba hacia abajo, pero ¿dón¬ 
de se empiezan a buscar los procesos que serán los módulos? Probablemente, el mejor lugar 
para buscar esta información es en el diagrama de flujo de datos (véase el capítulo 7). 

Al transformar un diagrama de flujo de datos en un diagrama de estructura, se deben 
tener en cuenta varias consideraciones adicionales. El diagrama de flujo de datos indicará 
la secuencia de los módulos en un diagrama de estructura. Si un proceso proporciona en- 
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trada a otro proceso, los módulos correspondientes se deben desempeñar en la misma se¬ 
cuencia. La figura 16.10 es un diagrama de flujo de datos para preparar un informe de 
calificación del estudiante. Observe que el proceso 1, LEER REGISTRO DE CALIFICA¬ 
CIÓN, proporciona entrada para el proceso 2, LEER REGISTRO DEL CURSO, y para el 
proceso 3, LEER REGISTRO DEL ESTUDIANTE. En la figura 16.11 se ilustra el diagra¬ 
ma de estructura creado para este diagrama. Observe que el módulo 110, LEER REGIS¬ 
TRO DE CALIFICACIÓN, se debe ejecutar primero. Después se deben ejecutar los pro¬ 
cesos 2 y 3, pero debido a que no proporcionan entrada para otros, el orden de estos 
módulos (120 y 130) en el diagrama de estructura no es importante y se podría invertir 
sin afectar los resultados finales. Los procesos 1 y 2 proporcionan entrada para el proceso 
4, CALCULAR MEDIA DE PUNTO DE CALIDAD (también conocido como módulo 
140). El proceso 5, IMPRIMIR INFORME DE CALIFICACIÓN DEL ESTUDIANTE 
(módulo 150), recibe flujo de datos de todos los demás procesos y debe ser el último mó¬ 
dulo en ser ejecutado. 

Si un proceso se divide en un diagrama de flujo de datos hijo, ei módulo correspondien¬ 
te para el proceso padre tendrá módulos subordinados que correspondan a los procesos 
encontrados en el diagrama hijo. El proceso 5, IMPRIMIR INFORME DE CALIFICACIÓN 
DEL ESTUDIANTE, tiene cuatro flujos de datos de entrada y uno de salida y por ello es 
buen candidato para un diagrama hijo. En la figura 16.12 se ilustra el diagrama 5, los deta- 
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lies del proceso 5. Los procesos en el diagrama 5 traducen los módulos subordinados al mó¬ 
dulo 150, IMPRIMIR INFORME DE CALIFICACIÓN DEL ESTUDIANTE. 


TIPOS DE MÓDULOS 

Los módulos del diagrama de estructura entran en una de las tres categorías generales: (1) 
control, (2) transformacional (a veces denominado trabajador) o (3) funcional. Al producir 
un diagrama de estructura que es fácil de desarrollar y modificar, se debe tener cuidado de 
no mezclar los diferentes tipos de módulos. 

Los módulos de control normalmente se encuentran cerca de la parte superior del dia¬ 
grama de estructura y contienen la lógica para desempeñar los módulos de nivel inferior. 
Los módulos de control podrían estar, o no estar, representados en el diagrama de flujo de 
datos. Los tipos de instrucciones que normalmente están en los módulos de control son IF, 
PERFORM y DO. Las instrucciones detalladas tal como ADD y MOVE normalmente se 
mantienen al mínimo. Con frecuencia la lógica de control es la más difícil de diseñar; por lo 
tanto, los módulos de control no deben ser muy grandes. Si un módulo de control tiene más 
de nueve módulos subordinados, se deben crear nuevos módulos de control que sean subor¬ 
dinados del módulo de control original. La lógica de un módulo de control se podría de¬ 
terminar desde un árbol de decisión o una tabla de decisión. Una tabla de decisión con 
demasiadas reglas se debe dividir en varias tablas de decisión, con la primera tabla llamando 
a ejecución a la segunda tabla. Cada tabla de decisión produciría un módulo de control. 
(Véase el capítulo 9 para más información de los árboles y tablas de decisión.) 

Los módulos transformacionales son aquéllos creados de un diagrama de flujo de datos. 
Normalmente desempeñan una sola tarea, aunque varias tareas secundarias se podrían aso¬ 
ciar con la principal. Por ejemplo, un módulo denominado IMPRIMIR LÍNEA TOTAL 
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DEL CLIENTE podría formatear toda la línea, imprimir la línea, agregarla a los totales fina¬ 
les y establecer los totales del cliente a cero en la preparación para acumular las cantidades 
del siguiente cliente. Los módulos transformacionales normalmente incluyen una mezcla de 
instrucciones, unas cuantas instrucciones IF y PERFORM o DO y muchas instrucciones 
detalladas tales como MOVE y ADD. Estos módulos son inferiores en la estructura que los 
módulos de control. 

Los módulos funcionales son los más bajos en la estructura, rara vez tienen un módulo 
subordinado bajo ellos. Sólo desempeñan una tarea, tal como formatear, leer, calcular o es¬ 
cribir. Algunos de estos módulos se encuentran en un diagrama de flujo de datos, pero otros 
se tendrían que agregar, tal como leer un registro o imprimir una línea de error. 

La figura 16.13 representa el diagrama de estructura para agregar las reservaciones para 
los huéspedes de un hotel. Los módulos 000, AGREGAR RESERVACIÓN DEL HUÉS¬ 
PED y 100, AGREGAR RESERVACIÓN DEL CUARTO, son módulos de control que re¬ 
presentan el programa entero (módulo 000) y proporcionan el control necesario para hacer 
una reservación de cuarto (módulo 100). El módulo 110, DESPLEGAR PANTALLA DE 
RESERVACIÓN, es un módulo funcional responsable de mostrar la pantalla de reserva¬ 
ción inicial. Los módulos 120, OBTENER RESERVACIÓN DE CUARTO VÁLIDA, y 
160, CONFIRMAR RESERVACIÓN DEL CUARTO, son los módulos de control de nivel 
inferior. 

El módulo 120, OBTENER RESERVACIÓN DE CUARTO VÁLIDA, se desempeña 
repetidamente hasta que los datos de la reservación sean válidos o hasta que el operador de 
la reservación cancele la transacción. Este tipo de módulo OBTENER RESERVACIÓN... 
desahoga el módulo 100 de una cantidad considerable de código complejo. Los módulos su¬ 
bordinados para OBTENER RESERVACIÓN DE CUARTO VÁLIDA son módulos funcio- 
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nales responsables de recibir la pantalla de reservación, editar o validar la reservación del 
cuarto y mostrar una pantalla de error si los datos de entrada no son válidos. Debido a que 
estos módulos están en un bucle, el control permanece en esta parte de la estructura hasta 
que los datos de la pantalla sean válidos. 

El módulo 160, CONFIRMAR RESERVACIÓN DEL CUARTO, también se desempe¬ 
ña repetidamente y permite al operador verificar que se haya introducido la información 
correcta. En esta situación, el operador inspeccionará la pantalla y presionará una tecla es¬ 
pecificada, tal como Enter, si los datos son correctos, o una tecla diferente para modificar o 
cancelar la transacción. De nuevo, el programa permanecerá en estos módulos, repitiéndose 
hasta que el operador acepte o cancele la reservación. 

El módulo 190 es un módulo transformacional que formatea el REGISTRO DE RE¬ 
SERVACIÓN y desempeña el módulo 200 para escribir el REGISTRO DE RESERVA¬ 
CIÓN. Los módulos 130, 140, 150,170,180 y 200 son módulos funcionales que desempe¬ 
ñan una sola tarea: aceptar una pantalla, desplegar una pantalla o editar o escribir un 
registro. Estos módulos son los más fáciles de codificar, depurar y mantener. 


SUBORDINACIÓN DE MÓDULO 

Un módulo subordinado es uno inferior en el diagrama de estructura llamado por otro mó¬ 
dulo superior en la estructura. Cada módulo subordinado debe representar una tarea que es 
una parte de la función del módulo de nivel superior. Permitir que el módulo de nivel in¬ 
ferior desempeñe una tarea que no es requerida por el módulo que lo llama se denomina 
subordinación inadecuada. En tal caso, el módulo inferior se debe mover al nivel superior 
de la estructura. 

La figura 16.14 ilustra este concepto mediante un diagrama de estructura para cambiar 
un archivo MAESTRO DE CLIENTES. Examine el módulo 120, LEER MAESTRO DE 
CLIENTES. Éste tiene la tarea de usar el NÚMERO DEL CLIENTE de CAMBIAR RE- 
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GISTRO DE TRANSACCIÓN para obtener directamente la coincidencia del REGISTRO 
DEL CLIENTE. Si no se encuentra el registro, se imprime una línea de error. Por otra par¬ 
te, el MAESTRO DE CLIENTES se cambia y se vuelve a escribir el registro. Este módulo 
debe ser un módulo funcional, que simplemente lee un registro, pero en cambio tiene tres 
módulos subordinados. La pregunta debe ser, "¿Se debe imprimir una línea de error para lo¬ 
grar la lectura del MAESTRO DE CLIENTES?" Además, "¿Se debe formatear y volver a es¬ 
cribir el MAESTRO DE NUEVOS CLIENTES para leer el MAESTRO DE CLIENTES?" 
Debido a que la respuesta es no para ambas preguntas, los módulos 130,140 y 150 no deben 
ser subordinados de LEER MAESTRO DE CLIENTES. 

La figura 16.15 muestra el diagrama de estructura modificado. Las instrucciones de 
control se sacaron del registro LEER MAESTRO DE CLIENTES y se pusieron en el módu¬ 
lo de control principal, CAMBIAR. REGISTRO DEL CLIENTE. LEER MAESTRO DE 
CLIENTES se vuelve un módulo funcional (módulo 120). 

Aun cuando un diagrama de estructura logra todos los propósitos para los cuales fue 
diseñado, no puede ser la única técnica usada para diseño y documentación. Primero, no 
muestra el orden en que se deben ejecutar los módulos (un diagrama de flujo de datos lo 
hará). Segundo, no muestra suficientes detalles (un pseudocódigo lo hará). El resto de es¬ 
te capítulo discute estas técnicas más detalladas usando como ejemplo el problema de 
suscripción a un periódico presentado anteriormente, el cual se describe ahora con más 
detalle. 




Diagrama de: estructura que 
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Diagrama de estructura 

modificado que muestra ......... 

la subordinación adecuada. INGENIERÍA DE SOFTWARE Y DOCUMENTACIÓN 

La planeación y control son elementos fundamentales en todo sistema exitoso. En el desa¬ 
rrollo de software para el sistema, el analista de sistemas debe saber que la planeación tiene 
lugar en el diseño, incluso antes de que empiece la programación. Necesitamos técnicas que 
nos ayuden a establecer los objetivos del programa, de manera que nuestros programas estén 
completos. También necesitamos técnicas de diseño que nos ayuden a separar el esfuerzo de 
programación en módulos manejables. 

Sin embargo, no es satisfactorio intentar tener éxito tan sólo con las etapas de la planea¬ 
ción. Después de que se completan los programas, se deben mantener y los esfuerzos de 
mantenimiento normalmente son mayores que el esfuerzo empleado en el diseño y la pro¬ 
gramación originales. 

Las técnicas descritas en la siguiente sección no sólo están hechas para usarse inicial¬ 
mente en el diseño de software, sino también en su mantenimiento. Debido a que la mayoría 
de los sistemas no se consideran desechables, muy probablemente necesitarán ser manteni¬ 
dos. El esfuerzo de aseguramiento de la calidad total requiere que los programas se docu¬ 
menten adecuadamente. 

El software y los procedimientos se documentan de manera que se codifiquen en un 
formato que se pueda acceder fácilmente. El acceso a esta documentación es necesario para 
las nuevas personas que aprenden el sistema y como un recordatorio para aquellos que no 
usan el programa con frecuencia. La documentación permite a usuarios, programadores y 
analistas "ver" el sistema, su software y procedimientos sin tener que interactuar con él. 

Cierta documentación proporciona una apreciación global del propio sistema, mientras 
que la documentación de procedimiento detalla lo que se debe hacer para ejecutar el software 
en el sistema y la documentación del programa detalla el código del programa que se usa. 

La rotación del personal de servicio de información tradicionalmente ha sido alta 
en comparación con otros departamentos, de manera que probablemente las personas que 
concibieron e instalaron el sistema original no serán las mismas que las que lo mantienen. 
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La documentación consistente y bien actualizada acortará el número de horas requerido 
para que las nuevas personas aprendan el sistema antes de realizar el mantenimiento. 

Hay muchas razones por las cuales los sistemas y programas no están documentados o 
presentan subdocumentación. Algunos de los problemas residen en los sistemas y progra¬ 
mas, otros en los analistas de sistemas y programadores. 

Algunos sistemas heredados fueron escritos antes de que un negocio estandarizara sus 
técnicas de documentación, pero todavía se usan (sin documentación]. Muchos otros siste¬ 
mas han sufrido modificaciones mayores o menores y se han actualizado durante los años, 
pero su documentación no se ha modificado para reflejar esto. Incluso se puede dar el caso 
que se hayan comprado algunos sistemas especializados para aplicaciones importantes a pe¬ 
sar de su falta de documentación. 

Los analistas de sistemas podrían no documentar adecuadamente los sistemas debido a 
que no tienen tiempo o no se les paga por el tiempo usado en la documentación. Algunos 
analistas no documentan porque tienen miedo de hacerlo o piensan que no es su trabajo. 
Además, muchos analistas son reservados sobre documentar sistemas que no son suyos, qui¬ 
zás temen a las represalias si incluyen material incorrecto en el sistema de alguien más. La 
documentación lograda por medio de una herramienta CASE durante las fases del análisis 
puede resolver muchos de estos problemas. 

Actualmente no se usa una sola técnica estándar de diseño y documentación. En las si¬ 
guientes secciones, discutimos varias técnicas diferentes que actualmente se usan. Cada 
técnica tiene sus propias ventajas y desventajas, debido a que cada una tiene propiedades 
únicas. 

PSEUDQCÓD1G0 

En el capítulo 9, introdujimos el concepto de español estructurado como una técnica de 
analizar decisiones. El pseudocódigo es similar al español estructurado porque no es un tipo 
particular de programar código, pero se puede usar como un paso intermedio para desarro¬ 
llar el código de programa. 

La figura 16.16 es un ejemplo de pseudocódigo para Chenoweth Enterprises, un con¬ 
glomerado del periódico que publica el Charlie Brown ’s Journal, The Steel Pier Observer y 
Wicked, el siempre popular periódico orientado a adolescentes. El conglomerado del perió¬ 
dico pasa por un proceso de actualizar, imprimir y proporcionar informes de administración 
para cada uno de sus periódicos. El pseudocódigo para este proceso involucra un proceso de 
actualizar cada lista de suscriptores al periódico. Esta estructura se puede ver fácilmente en 
el pseudocódigo. 

En la industria es común el uso del pseudocódigo, pero la falta de estandarización evi¬ 
tará que sea aceptado por todos. Debido a que el pseudocódigo está tan cerca del código de 
programa, naturalmente es favorecido por programadores y por consiguiente no es favoreci¬ 
do por analistas de negocios. El pseudocódigo con frecuencia se usa para representar la lógi¬ 
ca de cada módulo en un diagrama de estructura. 

El diagrama de flujo de datos se podría usar para escribir la lógica del pseudocódigo. Al 
usar un nivel del programa en lugar de un nivel del sistema, el diagrama de flujo de datos 
podría agregar varios símbolos adicionales. El asterisco (*], que significa "y", se usa para in¬ 
dicar que deben estar presentes los dos flujos de datos nombrados. Consulte la parte de un 
diagrama de flujo de datos que se ilustra en la figura 16.17. Si los flujos de datos de entrada 
son de procesos diferentes, la presencia del conectar "y" significa que el proceso que recibe 
el flujo debe desempeñar alguna clase de coincidencia de archivo o una coincidencia se- 
cuenciaL leer todos los registros de ambos archivos o una lectura indexada de un segundo 
archivo usando un campo importante obtenido del primer archivo. 

El signo de suma encerrado en un círculo (fifi] representa un "o" exclusivo e indica que 
uno u otro flujo de datos está presente en cualquier momento dado. Usar este símbolo im¬ 
plica que el proceso que recibe o produce el flujo de datos debe tener una instrucción co¬ 
rrespondiente IF... THEN... ELSE... 
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MANUALES DE PROCEDIMIENTO 

Los manuales de procedimiento son documentos organizacionales comunes que la mayoría 
de las personas ha visto. Son el componente en Español de la documentación, aunque tam¬ 
bién podrían contener códigos de programa, diagramas de flujo, etc. Se pretende que los 
manuales comuniquen a aquellos que los usan. Podrían contener comentarios de fondo, 
los pasos requeridos para lograr diferentes transacciones, instrucciones de cómo recuperar¬ 
se de los problemas y qué hacer si algo no funciona (solucionar problemas]. Actualmente 
muchos manuales están disponibles en línea, con capacidad de hipertexto que facilita el uso. 

Se desea un enfoque directo y estandarizado para crear documentación de apoyo de 
usuario. Para ser útil, la documentación del usuario se debe mantener actualizada. El uso 
de Web ha revolucionado la velocidad con que los usuarios pueden obtener asistencia. 
Muchos diseñadores de software están desplazando el soporte de usuario —con la lista de 
preguntas frecuentes (FAQ), escritorios de ayuda, soporte técnico y servicios de fax— para 
Web. Además, muchos vendedores de software COTS incluyen archivos "Léame" con des¬ 
cargas o envíos de nuevo software. Estos archivos sirven para varios propósitos: documentan 
cambios, ajustan o reparan fallas recientemente descubiertas en la aplicación que han ocu¬ 
rrido demasiado tarde en su desarrollo para poder ser incluidas en el manual del usuario. 
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Las secciones importantes de un manual deben incluir una introducción, cómo usar el 
software, qué hacer si las cosas salen mal, una sección de referencia técnica, un índice e in¬ 
formación de cómo contactar al fabricante. Los manuales en línea en los sitios Web también 
deben incluir información sobre descargar actualizaciones y una página de FAQ. Los pro¬ 
blemas con los manuales de procedimiento son que (1) están mal organizados, (2) es difícil 
encontrar la información necesaria en ellos, (3] el caso específico en cuestión no aparece en 
el manual y (4] el manual no está escrito en español. Más adelante, en la sección donde se 
habla de pruebas, discutimos la importancia de tener usuarios que "prueban" los manuales 
de sistemas y prototipos de los sitios Web antes de que se terminen. 


EL MÉTODO DE FOLKLORE 


El FOLKLORE es una técnica de documentación de sistemas creada para complementar 
algunas de las técnicas ya tratadas. Aun con la abundancia de técnicas disponibles, muchos 
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FOLKLORE 


sistemas se documentan inadecuadamente o no se documentan en absoluto. El FOLKLO¬ 
RE recopila información que normalmente se comparte entre los usuarios pero raramente 
se pone por escrito. 

El FOLKLORE es una técnica sistemática, basada en métodos tradicionales usados 
para recopilar el folklore sobre las personas y leyendas. Este enfoque para la documentación 
de sistemas requiere que el analista entreviste a los usuarios, investigue la documenta¬ 
ción existente en los archivos y observe el procesamiento de información. El objetivo es 
recopilar la información correspondiente a una de cuatro categorías: costumbres, anécdo¬ 
tas, proverbios y formas artísticas. La figura 16.18 sugiere cómo se relaciona cada categoría 
a la documentación de sistemas de información. 

Al documentar las costumbres, el analista (u otro folklorista) intenta capturar por es¬ 
crito lo que los usuarios hacen para conseguir que los programas puedan ejecutar sin pro¬ 
blemas. Un ejemplo de una costumbre es: "Normalmente, nos toma dos días actualizar los 
registros mensuales porque la tarea es bastante grande. Ejecutamos cuentas comerciales en 
un día y guardamos las otras para el siguiente día". 

Las anécdotas son historias que los usuarios dicen respecto a cómo funcionó el sistema. 
Por supuesto, la exactitud de la anécdota depende de la memoria del usuario y es, en el me¬ 
jor de los casos, una opinión sobre cómo funcionó el programa. Lo siguiente es un ejemplo 
de una anécdota: 


El problema ocurrió de nuevo en 1995. Esa vez, el trabajo LIB409 (actualización 
mensual) sólo se ejecutó con los registros "tipo 6". Debido a este error, no había re¬ 
gistros financieros en el archivo LIBFIN. Cuando intentamos leer el archivo vacío, 
éste inmediatamente se cerraba y por consiguiente los totales se reportaron como 
cero. Pudimos corregir este problema agregando un registro "tipo 7" y ejecutando 
el trabajo. 


Las anécdotas normalmente tienen un principio, un cuerpo y un fin. En este caso, tenemos 
una historia sobre un problema (el principio), una descripción de los efectos (el cuerpo) y 
la solución (el fin). 

Los proverbios son declaraciones breves que representan generalizaciones o consejos. 
Tenemos muchos proverbios en la vida cotidiana, tal como "Más vale pájaro en mano que 
ciento volando" o "centavo ahorrado, centavo ganado". En la documentación de sistemas, te¬ 
nemos muchos proverbios, tal como "Omita esta sección de código y el programa fallará" o 
"Haga frecuentemente copias de seguridad". A los usuarios les gusta dar consejos y el analis¬ 
ta debe intentar capturar dichos consejos e incluirlos en la documentación de FOLKLORE. 

Recopilar formas artísticas es otra actividad importante de folkloristas tradicionales, y 
también el analista de sistemas debe entender su importancia. Los diagramas de flujo, dia¬ 
gramas y tablas que los usuarios diseñan algunas veces podrían ser mejores o más útiles que 
los diseñados por el autor del sistema original. Los analistas con frecuencia encontrarán tal 
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ESCRIBIR ES CORRECTO 


"Es fácil de entender. Creo que si todos usamos pseudocódígo, no 
tendremos problemas, es decir, con cosas que no se. estén estandarizan¬ 
do". dice Al Gorithm, un nuevo programador que trabajará con su equipo 
de análisis de sistemas. Al participa en una reunión informal con tres 
miembros del equipo de análisis de sistemas, un grupo de trabajo de MIS 
compuesto por seis miembros del departamento de publicidad, y dos 
programadores, quienes trabajan en equipo para desarrollar un sistema 
de información para el personal de publicidad:: : 

, Philip, un ejecutivo descuenta.del área de. publicidad y.miembro del 
grupo de trabajo de MIS, pregunta sorprendido;: "¿Cómo se llama este 
método?". Los dos programadores contestan al mismo tiempo: "Pseudo¬ 
códígo". Philip contesta, imperturbable: "Eso .no.me dice nada". 

Neeva Phail, una de las analistas de sistemas, empieza-a explicar:. 
"Tal vez no importe tanto lo que utilicemos, ., 

■ FioChart, otra analista de sistemas, la interrumpe: "Yo odio el pseu¬ 
docódígo". Fío mira a los programadores en: busca de apoyo. "Estoy se-: 
gura de que podemos ponernos.de acuerdo en una mejortécníca." 


David,fun ejecutivo de publicidad más experimentado, parece un po¬ 
co disgustado y dice:. "Yo. aprendí algo de los diagramas de flujo con los 
. primeros ánalistas de sistemas que tuvimos hace años. ¿Ustedes ya no 
ios utilizan? Creo que son una mejor opción". 

Lo que al principio era una reunión amistosa repentinamente parece 
haber llegado a un callejón sin salida. Los participantes se miran unos a 
otros con recelo. Como un analista de sistemas que ha trabajado en mu¬ 
chos proyectos diferentes con muchos tipos distintos de personas, usted 
comprende que el grupo espera que usted haga algunas sugerencias ra¬ 
zonables. 


Con base en lo que usted conoce sobre las diversas técnicas de docu¬ 
mentación, ¿qué técnica(s) propondría a los miembros del grupo? ¿De 
qué manera la(s) técnica(s) que usted proponga solucionará(n) algunas 
dé las: preocupaciones cjue han expresado los miembros del grupo? ¿Qué 
proceso utilizará para elegir las técnicas apropiadas? 


arte en los carteles de anuncios o podrían pedir a los usuarios vaciar sus archivos y recupe¬ 
rar cualquier diagrama útil. 

El enfoque FOLKLORE funciona debido a que puede ayudar a reparar la falta de 
conocimiento cuando un autor de programa se retira. Los contribuyentes al documento 
FOLKLORE no tienen que documentar el sistema entero, sólo las partes que conozcan. Por 
último, es divertido para los usuarios contribuir, quitando así algo de carga de los analistas. 
Observe que la clase de sistemas de recomendación que se discutió anteriormente en el li¬ 
bro está muy cerca de la conceptualización de FOLKLORE. Estos sistemas amplían la idea 
de FOLKLORE para incluir todos los tipos de recomendaciones, tales como las calificacio¬ 
nes de restaurantes y películas. Usando métodos económicos o gratuitos como el correo 
electrónico, se han superado algunas barreras iniciales para recopilar y compartir la informa¬ 
ción informal. 

El peligro de confiar en el FOLKLORE es que la información recopilada de los usua¬ 
rios podría ser correcta, parcialmente correcta o incorrecta. Sin embargo, a menos que al¬ 
guien se tome el tiempo de rehacer completamente la documentación de programa, la des¬ 
cripción de costumbres, anécdotas, proverbios y formas artísticas podría ser la única 
información escrita acerca de cómo funciona un grupo de programas. 


SELECCIÓN DE UNA TÉCNICA DE DISEÑO Y DOCUMENTACIÓN 

Las técnicas discutidas en este capítulo son sumamente valiosas como herramientas de di¬ 
seño, ayudas de memoria, herramientas de productividad y como medios de reducir las 
dependencias en los miembros de personal clave. Sin embargo, el analista de sistemas se en¬ 
frenta con una decisión difícil con respecto a qué método adoptar. Lo siguiente es un grupo 
de lincamientos para ayudar al analista a seleccionar la técnica adecuada. 

Escoja una técnica que: 

1. Es compatible con la documentación existente. 

2. Se entiende por otros en la organización. 

3. Le permite regresar a trabajar en el sistema después de que ha estado fuera de él por un 
periodo. 

4. Sea conveniente para el tamaño del sistema en que está trabajando. 
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5. Permita un enfoque de diseño estructurado si se considera como más importante que 
otros factores. 

6. Permita fácil modificación. 


cómo probar' mantener y auditar 

Una vez que el analista ha diseñado y codificado el sistema, probar, mantener y auditar son 
las primeras consideraciones. 


EL PROCESO DE PROBAR 

Todos los programas de aplicación del sistema recién escritos o modificados —así como 
también nuevos manuales de procedimiento, nuevo hardware y todas las interfaces del sis¬ 
tema— se deben probar completamente. Probar al azar y por tanteo no será suficiente. 

Las pruebas se hacen durante todo el proceso de desarrollo de sistemas, no sólo al final. 
Se busca descubrir errores desconocidos hasta ahora, no demostrar la perfección de progra¬ 
mas, manuales o equipo. 

Aunque probar es tedioso, es una serie esencial de pasos que ayuda a asegurar la calidad 
del eventual sistema. Es mucho menos inquietante probar de antemano que tener un siste¬ 
ma probado deficientemente que falle después de la instalación. Las pruebas se realizan en 
subsistemas o módulos del programa conforme avance su desarrollo. Las pruebas se hacen 
en muchos niveles diferentes a varios intervalos. Antes de que el sistema se ponga en pro¬ 
ducción, todos los programas se deben verificar en el escritorio, verificar con datos de prue¬ 
ba y verificar para ver si los módulos trabajan entre sí como se planeó. 

El sistema también se debe probar como un todo en funcionamiento. Incluso hay que 
probar las interfaces entre los subsistemas; la exactitud de salida; y la utilidad y entendi¬ 
miento de la documentación y salida de sistemas. Como se muestra en la figura 16.19, los 
programadores, analistas, operadores y usuarios cumplen un papel diferente en los varios 
aspectos a probar. Las pruebas de hardware normalmente se proporcionan como un servi¬ 
cio por los vendedores de equipo quienes ejecutarán sus propias pruebas en el equipo cuan¬ 
do se libere en el sitio. 

Pruebas de programas con datos de prueba Mucha de la responsabilidad para probar el 
programa radica en el autor(es) original de cada programa. El analista de sistemas sirve co¬ 
mo consejero y coordinador para las pruebas del programa. En esta capacidad, el analista 
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operadores y usuarios 
desempeñan un papel diferente 
en probar el software y sistemas. 
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trabaja para asegurar que los programadores implementen las técnicas de prueba correctas 
pero probablemente no desempeñe personalmente este nivel de verificación. 

En esta fase, los programadores primero deben hacer pruebas de escritorio de sus pro¬ 
gramas para verificar la forma en que funcionará el sistema. En la verificación de escritorio, 
el programador sigue cada paso en el programa impreso para verificar si la rutina funciona 
como se espera. 

Luego, los programadores deben crear datos de prueba válidos e inválidos. Estos datos 
se ejecutan después para ver si las rutinas de base trabajan y también para descubrir errores. 
Si la salida de los módulos principales es satisfactoria, pueden agregar más datos de prueba 
para verificar otros módulos. Los datos de prueba creados deben probar posibles valores mí¬ 
nimos y máximos así como también todas las variaciones posibles en el formato y códigos. 
Los archivos de salida de los datos de prueba se deben verificar cuidadosamente. Nunca se 
debe asumir que los datos contenidos en un archivo son correctos sólo porque un archivo 
fite creado y accesado. 

A lo largo de este proceso, el analista de sistemas verifica la salida en busca de errores, 
avisando al programador de cualesquier correcciones necesarias. El analista normalmente 
no recomendará o creará datos de prueba para las pruebas de programas pero podría seña¬ 
lar al programador las omisiones de tipos de datos a ser agregados en pruebas posteriores. 

Prueba de vínculos con datos de prueba Cuando los programas pasan la verificación de 
escritorio y la verificación con datos de prueba, se deben pasar por las pruebas de vínculos, que 
también se conocen como prueba de cadena. Estas pruebas verifican si los programas 
que realmente son interdependientes trabajan juntos como se planeó. 

Una pequeña cantidad de datos de prueba, normalmente diseñados por el analista de . 
sistemas para probar las especificaciones del sistema así como también los programas, se usa 
para las pruebas de vinculación. Podría tomar varios pasos a través del sistema para probar 
todas las combinaciones, debido a que es inmensamente difícil resolver los problemas si in¬ 
tenta probar todo a la vez. 

El analista crea datos de prueba especiales que cubren una variedad de situaciones de 
procesamiento para la prueba de vinculación. Primero, se procesan datos de prueba típicos 
para ver si el sistema puede manejar transacciones normales, aquellas que constituirían el 
mayor volumen de su carga. Si el sistema funciona con transacciones normales, se agregan 
las variaciones, incluyendo los datos inválidos para asegurar que el sistema puede detectar 
adecuadamente los errores. 

Prueba completa de sistemas con datos de prueba Cuando las pruebas de vinculación se 
concluyen satisfactoriamente, se debe probar el sistema como una entidad completa. En es¬ 
ta fase, los operadores y usuarios finales se involucran activamente en la prueba. Los datos 
de prueba, creados por el equipo de análisis de sistemas para el propósito expreso de probar 
los objetivos del sistema, se usan. 

Como se puede esperar, hay varios factores a considerar cuando se prueban los sistemas 
con datos de prueba: 

1. Examinar si los operadores tienen la documentación adecuada en los manuales de pro¬ 
cedimiento (en papel o en línea) para asegurar un funcionamiento correcto y eficaz. 

2. Verificar si los manuales de procedimiento son lo bastante claros como para comunicar 
cómo se deben preparar los datos para la entrada. 

3. Determinar si los flujos de trabajo necesarios para el sistema nuevo o modificado real¬ 
mente "fluyen". 

4. Determinar si la salida es correcta y si los usuarios entienden que esta salida es como se 
verá en su formulario final. 

Recuerde fijar el tiempo adecuado para la prueba del sistema. Desafortunadamente, con 
frecuencia este paso se elimina si la instalación del sistema se retrasa de la fecha indicada. 

La prueba de sistemas incluye reafirmar los estándares de calidad para el desempeño 
del sistema que se estableció cuando se hicieron las especificaciones iniciales del sistema. 
Todos los involucrados deben estar de acuerdo una vez más en cómo determinar si el siste¬ 
ma está haciendo lo que se supone que hace. Este paso incluirá medidas de error, oportuni- 
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ESTUDIANDO PARA SU PRUEBA DE SISTEMAS 


"Tenemos el tiempo encima. Tan sólo mira esta proyección", dice Lou 
Scuntroll, el miembro más nuevo de su equipo de análisis de sistemas, 
mientras le muestra el diagrama PERT que el equipo ha estado usando 
para proyectar la fecha en que el nuevo sistema quedaría listo. "Quizá no 
podamos cumplir la fecha prevista de julio para realizar las pruebas con 
datos reales. Estamos atrasados tres semanas debido a que el equipo se 
embarcó tarde." 

Como uno de los analistas de sistemas que han vivido la presión de 
fijar y reprogramar fechas límite en otros proyectos, usted intenta per¬ 
manecer tranquilo y evaluar cuidadosamente la situación antes de ha¬ 
blar. Lentamente, usted plantea a Lou la posibilidad de postergar las 
pruebas. 

Lou contesta: "Si tratamos de retrasar las pruebas hasta las prime¬ 
ras semanas de agosto, en esas fechas dos personas importantes de 
contabilidad estarán de vacaciones". Lou está visiblemente molesto con 
la posibilidad de retrasar la fecha límite. 

Stan Dards, otro miembro reciente de su equipo de análisis de siste¬ 
mas, entra en la oficina de Lou. "Ambos tienen un aspecto pésimo. Todo 
está bien, ¿no es cierto? No me reasignaron a programar una aplicación 
de nómina, ¿o sí?" 

A Lou no le hace gracia el sentido del humor de Stan ni su aparente 
preocupación por sí mismo. "Todo estaba bien hasta antes de que llega¬ 
ras. Estábamos a punto de tomar algunas decisiones importantes sobre 
el calendario." Lou le pasa a Stan el diagrama PERT para que lo revise. 


"Observa la fecha de pruebas de julio. Como podrás darte cuenta, no hay 
manera de cumplirla. ¿Alguna brillante ¡dea?" 

Stan contempla unos instantes el diagrama, luego señala: "Algo ha 
pasado. Veamos aquí... quizá si movemos el módulo de contabilidad a..." 

Lou lo interrumpe bruscamente: "¡No!, ya pensamos en eso, pero 
Stanford y Binet, de contabilidad, están de vacaciones en agosto. Quizá 
podríamos omitir esa parte de las pruebas. Ellos han sido muy coopera¬ 
tivos. No creo que pongan ninguna objeción si sacamos los sistemas y 
hacemos las pruebas ya que estemos en la fase de producción”. 

"Creo que ésa es una buena idea, Lou", coincide Stan, tratando de con¬ 
graciarse con Lou después de sus bromas anteriores. "No hemos tenido 
ningún problema real con eso, y los programadores son confiables. Así po¬ 
dríamos mantener el calendario con todo lo demás. Yo voto por no probar la 
parte de contabilidad, y sólo darle un vistazo cuando se ponga en marcha." 

Como el miembro con más experiencia del equipo, ¿qué puede usted 
argumentar para convencer a Lou y Stan de la importancia de probar el 
módulo de contabilidad con datos reales? ¿Qué pueden hacer los analis¬ 
tas de sistemas para planificar sus actividades de tal manera que le de¬ 
diquen un tiempo razonable a realizar las pruebas con datos reales? 
¿Cuáles son algunos de los posibles problemas que los miembros del 
equipo podrían encontrar si no prueban el sistema completamente con 
datos reales antes de poner el sistema en producción? ¿Hay en el proce¬ 
so de análisis y diseño de sistemas pasos que puedan omitirse con el 
propósito de poner al día un proyecto retrasado? 


dades, facilidad de uso, clasificación apropiada de transacciones, tiempo fuera de servicio 
aceptable y manuales de procedimiento entendibles. 

Prueba completa de sistemas con datos reales Cuando las pruebas de sistemas con datos 
de prueba se realizan de manera satisfactoria, es bastante recomendable probar el nuevo sis¬ 
tema repetidas veces con lo que se conoce como datos reales, datos que se han procesado de 
manera exitosa con el sistema existente. Este paso permite una comparación precisa de la sa¬ 
lida del nuevo sistema con la salida que sabe ha sido procesada correctamente, y también es 
una buena opción para probar cómo se manejarán los datos reales. Obviamente, este paso no 
es posible al crear salidas completamente nuevas (por ejemplo, salida de una transacción de 
comercio electrónico de un nuevo sitio Web corporativo). Al igual que con los datos de prue¬ 
ba, sólo se usan pequeñas cantidades de datos reales en este tipo de prueba de sistemas. 

Las pruebas constituyen un periodo importante para evaluar la manera en que los 
usuarios finales y los operadores interactúan realmente con el sistema. Aunque se da mucha 
importancia a la interacción de usuario-sistema (véase el capítulo 14), nunca podrá prede¬ 
cir totalmente el amplio rango de diferencias en la forma en que los usuarios interactuarán 
realmente con el sistema. No basta con entrevistar a los usuarios sobre cómo interactúan 
con el sistema; debe observarlos directamente. 

Los aspectos que debe vigilar son la facilidad con que un usuario aprende el sistema y 
sus reacciones a la retroalimentación del sistema, incluyendo lo que hace cuando recibe un 
mensaje de error y cuando se le informa que el sistema está ejecutando sus comandos. Pon¬ 
ga especial atención a la manera en que reaccionan los usuarios al tiempo de respuesta del 
sistema y a la redacción de las respuestas. También escuche lo que dicen los usuarios acerca 
del sistema cuando trabajan en él. Es necesario resolver todos los problemas reales antes de 
que el sistema se ponga en producción, no sólo considerarlos como ajustes al sistema que 
los usuarios y operadores deben hacer por sí mismos. 
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Como se mencionó anteriormente, también los manuales de procedimiento necesitan 
ser probados. Aunque los manuales se pueden corregir por el personal de apoyo, y verificar 
su exactitud técnica por el equipo de análisis de sistemas, la única forma real de probarlos 
es tener usuarios y operadores que los prueben, de preferencia durante la prueba de siste¬ 
mas completos con datos reales. Haga que usen versiones precisas, pero no necesariamente 
versiones finales de los manuales. 

Es difícil comunicar con precisión los procedimientos. Demasiada información será 
como un obstáculo para el uso del sistema. El uso de documentos basados en Web puede 
ayudar en esta consideración. Los usuarios pueden pasar a los temas de interés y descargar e 
imprimir lo que quieren conservar. Considere las sugerencias del usuario e incorpórelas en 
las versiones finales de páginas Web, manuales impresos y otra documentación. 


PRÁCTICAS DE MANTENIMIENTO 

Su objetivo como analista de sistemas debe ser instalar o modificar sistemas que tienen una 
vida bastante útil. Quiere crear un sistema cuyo diseño es bastante comprensivo y previsivo 
para atender las necesidades actuales y proyectadas del usuario durante varios años. Debe 
usar parte de su experiencia para proyectar lo que podrían ser esas necesidades y después 
construir flexibilidad y adaptabilidad en el sistema. Lo mejor y más fácil del diseño de siste¬ 
mas será asegurar que el negocio tendrá que gastar menos dinero en el mantenimiento. 

Reducir los costos de mantenimiento es una consideración principal, debido a que el 
mantenimiento de software aislado puede consumir más de 50 por ciento del presupuesto 
de procesamiento de datos para un negocio. Los costos de mantenimiento excesivos se re¬ 
flejan directamente en el diseñador del sistema, debido a que aproximadamente 70 por 
ciento de errores de software se han atribuido al diseño de software inadecuado. Desde una 
perspectiva de sistemas, tiene sentido que detectar y corregir a tiempo los errores de diseño 
de software es menos costoso que permitir que permanezcan inadvertidos hasta que sea ne¬ 
cesario el mantenimiento. 

Por lo regular el mantenimiento se realiza para mejorar el software existente en lugar 
de responder a una crisis o falla del sistema. Al igual que con el cambio de requerimien¬ 
tos del usuario, el software y la documentación se deben cambiar como parte del trabajo de 
mantenimiento. Además, los programas se podrían recodificar para mejorar la eficacia del 
programa original. Más de la mitad de todo el mantenimiento está compuesto de dicho tra¬ 
bajo de mejora. 

El mantenimiento también se hace para actualizar el software en respuesta a la organi¬ 
zación cambiante. Este trabajo no es tan sustancial como mejorar el software, pero se debe 
hacer. El mantenimiento de emergencia y de adaptación representa menos de la mitad de 
todo el mantenimiento del sistema. 

Parte del trabajo del analista de sistemas es asegurar que en el lugar haya procedimien¬ 
tos y canales adecuados para permitir retroalimentación sobre —y respuestas subsecuentes 
para— las necesidades de mantenimiento. Los usuarios deben poder comunicar fácilmente 
los problemas y sugerencias a aquellos que estarán manteniendo el sistema. Es muy desalen¬ 
tador si el sistema no se mantiene adecuadamente. Las soluciones consisten en proporcionar 
a los usuarios acceso a correo electrónico para el soporte técnico, así como también permi¬ 
tirles descargar actualizaciones de producto o ajustes de Web. 

El analista de sistemas también necesita establecer un esquema de clasificación para 
permitir a usuarios designar la importancia percibida del mantenimiento sugerido o solici¬ 
tado. Clasificar las solicitudes permite a programadores de mantenimiento entender cómo 
estiman los usuarios la importancia de sus solicitudes. Este punto de vista, junto con otros 
factores, se puede tener en cuenta al establecer el mantenimiento. 


CÓMO AUDITAR 

Auditar es otra forma de asegurar la calidad de la información contenida en el sistema. Am¬ 
pliamente definido, auditar se refiere a pedirle a un experto, que no esté involucrado en 
crear o usar un sistema, examinar la información para determinar su fiabilidad. Ya sea que la 
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información se establezca o no para ser fiable, el descubrimiento en su fiabilidad se comu¬ 
nica a otros con el propósito de hacer la información del sistema más útil para ellos. 

Generalmente hay dos tipos de auditores para los sistemas de información: interno y 
externo. Determinar si ambos son necesarios para el sistema que usted diseña, dependerá de 
qué tipo de sistema es. Los auditores internos trabajan para la misma organización que po¬ 
see el sistema de información, mientras que los externos (también llamados independien¬ 
tes) se contratan por fuera. 

Los auditores externos se usan cuando el sistema de información procesa datos que in¬ 
fluyen en las declaraciones financieras de una compañía. Los auditores externos auditan el 
sistema para asegurar la veracidad de las declaraciones financieras que se producen. Tam¬ 
bién se podrían traer si ocurre algo fuera de lo normal que involucra a los empleados de la 
compañía, tal como la sospecha de un fraude electrónico o un desfalco. 

Los auditores internos estudian los controles usados en el sistema de información para 
estar seguros que son adecuados y que están haciendo lo que deben hacer. También prueban 
la suficiencia de controles de seguridad. Aunque trabajan para la misma organización, los 
auditores internos no informan a las personas responsables del sistema que están auditando. 
El trabajo de los auditores internos con frecuencia es más detallado que el de los auditores 
externos. 




RESU1EN 

El analista de sistemas usa tres enfoques amplios de la administración de calidad total 
(TQM) para analizar y diseñar sistemas de información: diseñar sistemas y software con un 
enfoque descendente y modular; diseñar y documentar sistemas y software usando méto¬ 
dos sistemáticos; y probar sistemas y software de manera que se puedan mantener y audi¬ 
tar fácilmente. 

Seis Sigma es una cultura, filosofía, metodología y enfoque para la calidad que tiene co¬ 
mo meta la eliminación de todos los defectos. Los siete pasos de un enfoque Seis Sigma son: 
(1) definir el problema; (2) observar el problema; (3) analizar las causas; [4] actuar en las 
causas; (5] estudiar los resultados; (6) estandarizar los cambios, y (7) sacar conclusiones. 

Los usuarios son extremadamente importantes para establecer y evaluar, desde varias 
dimensiones, la calidad de los sistemas de información de administración y de los sistemas 
de apoyo a la toma de decisiones. Se pueden involucrar en la evolución entera de sistemas a 
través del establecimiento de fuerza de tarea de SI o círculos de calidad. 

TQM se puede implementar con éxito al tomar un enfoque descendente (arriba a 
abajo) para diseñar. Este enfoque se refiere a observar primero los objetivos generales de la 
organización y después dividirlos en requerimientos manejables de subsistemas. El desarro¬ 
llo modular hace la programación, depuración y mantenimiento más fácil de lograr. La pro¬ 
gramación en módulos se complementa bien con un enfoque descendente. 

Dos sistemas vinculan programas en el entorno de Windows. Uno es DDE (intercam¬ 
bio dinámico de datos), el cual comparte código usando archivos de biblioteca de víncu¬ 
los dinámicos (DLL). Al usar DDE, un usuario puede almacenar datos en un programa y 
después usarlos en otro. Un segundo enfoque para vincular programas en Windows es OLE 
(vinculación e incrustación de objetos). Debido a su enfoque orientado a objetos, este mé¬ 
todo de vinculación es superior a DDE para vincular datos y gráficos de la aplicación. 

Una herramienta recomendada para diseñar un sistema con un enfoque descendente y 
modular se denomina diagrama de estructura. Se usan dos tipos de flechas para indicar los 
tipos de parámetros que se pasan entre los módulos. El primero se denomina pareja de 
datos y el segundo se denomina bandera de control. Los módulos de un diagrama de estruc¬ 
tura entran en una de tres categorías: control, transformacional (a veces denominado traba¬ 
jador) y funcional o especializado. 
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EXPERIENCIA C 


"Éste es un lugar fascinante para trabajar. Estoy seguro de que usted coincide conmigo aho¬ 
ra que ha tenido la oportunidad de observarnos. A veces creo que debe ser divertido ser de 
fuera... ¿no se siente como un antropólogo que descubre una nueva cultura? Recuerdo 
cuando llegué aquí por primera vez. Todo era tan nuevo, tan extraño. iVayal, incluso el idioma 
era diferente. No era un 'consumidor'; era un 'cliente'. No temamos 'departamentos'; tenía¬ 
mos 'unidades'. No es una cafetería para empleados; es la 'taberna'. Esto también sé aplica a 
la manera en que trabajamos. Todos tenemos diferentes maneras de enfocar las cosas. Creo 
que he logrado entender lo que Snowden quiere, pero también de vez en cuándo cometo al¬ 
gún error. Por ejemplo, si le doy trabajo en un disco, igual'de sencillo es para él verlo así que 
en un informe impreso. [Por eso también tengo dos computadoras en mi escritorio! Siempre 
lo veo a usted tomar tantos apuntes... Sin embargo, creo qué esto tiene sentido. Se supone 
que usted documenta lo que nosotros hacemos con nuestros sistemas e información, así co¬ 
mo lo que su equipo hace, ¿no es así?" ' O 



PREGUNTAS DE HYPERCASE 

1. Use el método FOLKLORE para completar la documentación del sistenia GEMS de la 
Unidad de Sistemas de Información Gerencial. Asegúrese de incluir costumbres, anéc¬ 
dotas, proverbios y formas artísticas. 

2. En dos párrafos, sugiera una manera de capturar los elementos de FOLKLORE en una 
PC de tal manera que no sea necesario usar un registro en papel. Asegúrese de que la 
solución que sugiera incluya gráficos y texto. 

3. Diseñe pantallas de entrada y salida para FOLKLORE que permitan ingresar datos 
con facilidad, y proporcione mensajes que recuerden de inmediato los elementos de 


FOLKLORE. 



En HyperCase puede, utilizar FOLKLORE, para documentar formas artísticas que .los usuarios 
hayan creado o recopilado para darle sentido a sus sistemas. 
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La parte de TQM es para ver que los programas y sistemas se diseñan, documentan y 
mantienen adecuadamente. Algunas de las técnicas estructuradas que pueden ayudar al 
analista de sistemas son pseudocódigo, manuales de procedimiento y FOLKLORE. El pseu- 
docódigo se usa con frecuencia para representar la lógica de cada módulo o diagrama de 
estructura. El pseudocódigo se puede usar para repasos estructurados. Los analistas de siste¬ 
mas deben escoger una técnica que se adapte bien con lo que se usó previamente en la 
organización y que permita flexibilidad y fácil modificación. 

La prueba de programas específicos, subsistemas y sistemas totales es esencial para la 
calidad. La prueba se hace para detectar cualesquier problemas existentes con los progra¬ 
mas y sus interfaces antes de que el sistema se use realmente. La prueba normalmente se 
hace en una forma ascendente, con códigos de programa que primero se verifican en el 
escritorio. La prueba del sistema completo con datos reales (datos reales que se han proce¬ 
sado exitosamente con el sistema viejo), se logra siguiendo varios pasos intermedios de 
prueba. Esta prueba proporciona una oportunidad de resolver cualesquier problemas que 
surjan antes de que el sistema se ponga en producción. 

El mantenimiento del sistema es una consideración importante. El software bien dise¬ 
ñado puede ayudar a reducir los costos de mantenimiento. Los analistas de sistemas necesi¬ 
tan establecer canales para recibir la retroalimentación del usuario en las necesidades del 
mantenimiento, debido a que los sistemas que no se mantienen quedarán obsoletos. Los si¬ 
tios Web pueden ayudar al respecto al proporcionar acceso a las actualizaciones de produc¬ 
tos e intercambios de correo electrónico con personal técnico. 

Los auditores internos y externos se usan para determinar la fiabilidad de la informa¬ 
ción del sistema. Ellos comunican sus resultados de la auditoría a otros para mejorar la uti¬ 
lidad de la información del sistema. 


PALABRAS Y FRASES CLAVE 


acoplamiento de sello 
administración de la calidad total (TQM) 
auditor interno 

bandera de control (interruptor) 
biblioteca de vínculos dinámicos (DLL) 
círculo de calidad de SI 
desarrollo modular 
diagrama de estructura 
diseño ascendente 
diseño descendente 
documentación de software 
FOLKLORE 

intercambio dinámico de datos (DDE) 
mantenimiento de software 
módulo de control 
módulo funcional 


módulo transformacional 
parejas de datos 

prueba completa de sistemas con datos 
de prueba 

prueba completa de sistemas con datos 
reales 

prueba de programas con datos de prueba 
prueba de vínculos con datos de prueba 
(prueba de cadenas) 
pseudocódigo 
repaso estructurado 
Seis Sigma 

subordinación inadecuada 
verificación de escritorio 
vinculación e incrustación de objetos 
(OLE) 


PREGUNTAS DE REPASO 

1. ¿Cuáles son los tres enfoques amplios disponibles para el analista de sistemas para lo¬ 
grar la calidad en los sistemas recientemente desarrollados? 

2. ¿Cuál es el factor más importante para establecer y evaluar la calidad de sistemas de in¬ 
formación o sistemas de apoyo a la toma de decisiones? ¿Por qué? 

3. Defina el enfoque de administración de la calidad total (TQM) conforme se aplica al 
análisis y diseño de sistemas de información. 

4. ¿Qué significa el término Seis Sigma? 

5. ¿Qué es un círculo de calidad de SI? 

6. Defina el significado de hacer un repaso estructurado. ¿Quién debe estar involucrado? 
¿Cuándo se debe hacer un repaso estructrurado? 
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7. Mencione las desventajas de tomar un enfoque ascendente para diseñar. 

8. Mencione las ventajas de tomar un enfoque descendente para diseñar. 

9. ¿Cuáles son las tres desventajas principales de tomar un enfoque de descendente para 
diseñar? 

10. Defina el desarrollo modular. 

11. Mencione cuatro lincamientos para la programación modular correcta. 

12. ¿Cómo ayudan los diagramas de estructura al analista? 

13. Mencione los dos tipos de flechas usados en los diagramas de estructura. 

14. ¿Por qué queremos mantener el número de flechas al mínimo al usar los diagramas de 
estructura? 

15. ¿Por qué se deben pasar hacia arriba las banderas de control en los diagramas de es¬ 
tructura? 

16. Mencione dos formas en que el diagrama de flujo de datos ayuda a construir un diagra¬ 
ma de estructura. 

17. Mencione las tres categorías de módulos. ¿Por qué se usan en los diagramas de estructura? 

18. ¿Cómo puede ayudar un sitio Web a mantener el sistema y su documentación? 

19. Proporcione dos razones que apoyen la necesidad de sistemas bien desarrollados y do¬ 
cumentación de software. 

20. Defina el pseudocódigo. 

21. Mencione las cuatro quejas principales que los usuarios expresan sobre los manuales de 
procedimiento. 

22. ¿En cuáles cuatro categorías el método de documentación de FOLKLORE recopila la 
información? 

23. Mencione seis lincamientos para escoger una técnica de diseño y documentación. 

24. ¿De quién es la responsabilidad principal para probar los programas de cómputo? 

25. ¿Cuál es la diferencia entre datos de prueba y datos reales? 

26. ¿Cuáles son los dos tipos de auditores de sistemas? 


PROBLEiAS 


1. Uno de los miembros de su equipo de análisis de sistemas ha estado desalentando los 
comentarios de los usuarios sobre los estándares de calidad, argumentando que debido 
a que ustedes son los expertos, realmente son los únicos que saben lo que constituye un 
sistema de calidad. En un párrafo, explique al miembro de su equipo por qué es impor¬ 
tante obtener las opiniones de los usuarios para la calidad del sistema. Use un ejemplo. 
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2. Dibuje un diagrama de estructura para el sistema de reporte de crédito en la figura 
16.EX1. 

3. Escriba el pseudocódigo para el problema 2. 

4. Escriba el pseudocódigo para la política de renta de Citrón Car proporcionada en la 
Oportunidad de consultoría 9.3. 

5. Escriba una tabla de contenidos detallada para un manual de procedimientos que ex¬ 
plique a los usuarios cómo conectarse a la red de cómputo de su escuela, así como tam¬ 
bién las políticas de la red (quién es un usuario autorizado, etc.}. Asegúrese de que el 
manual se escriba pensando en el usuario. 

6. Su equipo de análisis de sistemas está cerca de completar un sistema para Meecham 
Feeds. Roger está bastante seguro de que los programas que ha escrito para el sistema 
de inventario de Meecham funcionarán como se requiere, debido a que son similares a 
los programas que ha hecho antes. Su equipo ha estado muy ocupado y le gustaría em¬ 
pezar a realizar la prueba completa de sistemas tan pronto como sea posible. 

Dos miembros jóvenes de su equipo han propuesto lo siguiente: 

a. Omitir la verificación de escritorio de los programas (debido a que programas si¬ 
milares se verificaron en otras instalaciones; Roger está de acuerdo]. 

b. Hacer la prueba de vínculos con grandes cantidades de datos para comprobar que 
el sistema funcionará. 

c. Hacer la prueba completa de sistemas con grandes cantidades de datos reales para 
demostrar que el sistema está funcionando. 

Responda a cada uno de los tres pasos del programa de prueba propuesto. Explique su 
respuesta en un párrafo. 

7. Proponga un plan de pruebas modificado para Meecham Feeds (problema 6). Divida 
su plan en una secuencia de pasos detallados. 


PROYECTOS DE GRUPO 

1. Divida su grupo en dos subgrupos. Un subgrupo debe entrevistar a los miembros del 
otro subgrupo sobre sus experiencias al registrarse en una clase. Se deben diseñar pre¬ 
guntas para obtener información sobre costumbres, anécdotas, proverbios y formas ar¬ 
tísticas que ayudarán a documentar el proceso de registro de su escuela. 

2. Reúna a su grupo para desarrollar una página Web para un extracto de un manual de 
FOLKLORE que documente el proceso de registro para una clase, basado en el FOL¬ 
KLORE que se utilizó en las entrevistas del proyecto í. Recuerde incluir ejemplos de 
costumbres, anécdotas, proverbios y formas artísticas. 
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IIAGRAiACIÓN DE LA ESTRUCTURA 



"Aquí las tienes, como lo prometimos", dicen Chip y Anna triunfalmente al entregar sus es¬ 
pecificaciones a Mack Roe, el programador del proyecto. 

"Gracias", responde Mack. "Tengo mucho trabajo por delante." 

Mack empieza a crear un diagrama de estructura para cada programa y luego pasa al di¬ 
seño de cada módulo. En la figura E16.1 se muestra el diagrama de estructura PRODUCE 
SOFTWARE CROSS-REFERENCE REPORT. La "C" antes de cada número de módulo se 





Diagrama de estructura PRODUCE SOFTWARE CROSS-REFERENCE REPORT. El asterisco sencillo (*) 
; y el asterisco doble (•**) Indican la segunda y tercera ocurrencias del módulo Ci 40. 
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refiere al CROSS-REFERENCE REPORT (Visible Analyst requiere una letra como primer 
carácter en el nombre de un módulo). Este borrador es el primero que Mack utiliza en un 
repaso estructurado con Dee Ziner, una programadora con experiencia. 

Dee Ziner tiene varias sugerencias importantes para mejorar la estructura. Ella dice: 
"El módulo C130, PRINT ERROR LINE, está erróneamente subordinado al módulo de 
llamada C120, READ HARDWARE RECORD. Se podría hacer la pregunta: '¿El programa 
debe imprimir una línea de error para leer un HARDWARE RECORD?' Puesto que la res¬ 
puesta es no, el módulo debe colocarse en el mismo nivel que C120, READ HARDWARE 
RECORD". 

Dee continúa analizando la situaciíon con Mack, y dice: "Lo mismo ocurre con el mó¬ 
dulo 060, PRINT SUBTOTAL LINES. Esta no es una función de acumulación de subto¬ 
tales de hardware y por lo tanto no se debe llamar desde el módulo 050, ACCUMULATE 
HARDWARE SUBTOTALS". Dee continúa el repaso y plantea la pregunta: "¿Un SOFT¬ 
WARE RECORD se podría localizar en muchas máquinas?" Mack responde que eso sí es 
válido, y otro módulo de control, PRINT SOFTWARE CROSS-REFERENCE LINE, se in¬ 
cluye en el diagrama de estructura. 

Mack procede a incorporar los cambios al diagrama de estructura. Cuando se esta¬ 
blece la jerarquía correcta, se agrega el acoplamiento. Se pone especial cuidado a pasar el 
mínimo de datos y a pasar control sólo hacia arriba del diagrama de estructura. En la fi¬ 
gura E16.2 se iluestra la versión final. El módulo C116 es nuevo, y se utiliza el archivo 
SOFTWARE/HARDWARE RELATION para enlazar un SOFTWARE RECORD a mu¬ 
chos HARDWARE RECORDS. El SOFTWARE INVENTOR Y NUMBER se pasa hacia 
abajo del módulo y el archivo de relación se lee de manera aleatoria. El HARDWARE 
INVENTORY NUMBER y el interruptor de control RELATION NOT FOUND se pasan 
hacia arriba de la estructura. 

El diagrama de estructura final tiene una forma funcional. Unos cuantos módulos de 
control en la parte superior de la estructura, varios módulos trabajadores a la mitad y 
unos cuantos módulos especializados en la parte inferior le dan un aspecto general equi¬ 
librado. Todos los nombres de los módulos tienen la estructura verbo-adjetivo-sustantivo, 
y describen la tarea que se realiza una vez que termina la ejecución del módulo. Por ejem¬ 
plo, el módulo C150 tiene el verbo "accumulate", que describe la tarea que desempeña el 
módulo. "Subtotals", un sustantivo, se acumula, y "hardware" describe cuáles subtotales se 
acumulan. 

Cada uno de los módulos del diagrama de estructura se describió en el depósito. La fi¬ 
gura E16.3 ilustra la pantalla que describe la función del módulo C100, PRODUCE SOFT¬ 
WARE LINES. Observe que la descripción del módulo contiene pseudocódigo que muestra 
la lógica del módulo. Dado que PRODUCE SOFTWARE LINES es un módulo de control, 
su lógica debe consistir de bucles y toma de decisiones, con muy pocas instrucciones relati¬ 
vas a los detalles del procesamiento, como ADD o READ. 

Cada pareja de datos y control del diagrama de estructura se podría describir también 
en el depósito. El área Related to ofrece un vínculo a la entrada del depósito que contiene 
los detalles de los elementos contenidos en la pareja de datos. 

"Bueno, creo que estamos a punto de terminar los diagramas para los programadores", 
comenta Chip. 

"De crear los diagramas, sí", repone Anna, "pero les podemos dar un poco más". 

"¿Qué quieres decir?", pregunta Chip, un tanto desconcertado. 

"Usemos Visible Analyst para generar las tablas de la base de datos para Microsoft 
Access", responde Anna. "Pienso que podríamos comenzar con una de las entidades prin¬ 
cipales, como SOFTWARE MASTER, y utilizar la característica de generación de código 
de Visible Analyst." 
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DO READ SOFTWARE RECORD 
IFNOTEND-OF-FILE 

DO PRINT SOFTWARE CROSS-REFERENCE LINES 
UNTIL RELATION-END-FILE 
DO PRINT SUBTOTAL UNES 
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Pantana áe.l depósito para ei módulo PRODUCE SOFTWARE UNES.. 


Anna y Chip proceden a trabajar con Visible Analyst para asegurarse de que se hayan 
definido todos los elementos de SOFTWARE MASTER. Anna hace clic en Repository y en 
Genérate Datábase Schema. Seleccionan el diagrama COMPUTER SYSTEM y le dan el 
mismo nombre al esquema. Se genera el esquema completo para el sistema de cómputo. En 
la figura E16.4 se ilustra una parte del código que se generó. 

"Voy a copiar una parte del esquema para trabajar sólo con el SOFTWARE MASTER", 
comenta Anna a Chip. Anna copia el código SQL generado para el archivo SOFTWARE 
MASTER. El siguiente paso es crear una consulta en blanco en Microsoft Access. Anna eje¬ 
cuta Microsoft Access y crea la consulta. A continuación hace clic en el botón SQL y pega 
el archivo SOFTWARE MASTER en la ventana de SQL. 

"Tengo que cambiar el nombre de la tabla por el de SOFTWARE y cambiar el tipo de 
consulta a Make Table", continúa Anna. Le da el nombre SOFTWARE a la nueva tabla. 
Anna hace clic en el botón Run Query y cierra la consulta. 

"¿Qué ocurrió?", pregunta Chip desconcertado. "No veo ninguna salida." 


iiSílJi Ei 
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S üiEATE TfiBI£ Board Code *”**' 

b < 

|p Board_Code GHflR(3) NOT NULL, 

|M Board_Nane CllflR(2B) NOT NULL 

fe ” 

ip CltEfíTE TfIBLE Canpus_Build¡ng 

•I < 

Canpus_Code NUMBER NOT NULL, 

jfeT Canpus_Description CHflR(3B) NOT NULL 

I® ); 
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IIHEfiTE TfiBLE Computer 
( 

Harduare_Inuentory_Number 

Brand_Name 

Nodel 

Serial_Number 

Date_Purchased 

Purchase_Cost 

Replacenent_Cost 

MemorySize 

Hard_Di-ive_Capacity 

Second_Hard_Driue_Capacity 

Floppy„Disl{ette_Driue 

CD_ROM_Driue 

Zip_Driue_Connected 

Network 

Netuoi-l<_Connection_Name 


CIIBR(8) NOT NULL, 
CHfiRCIB) NOT NULL, 
CHfiR(12) NOT NULL, 
CHflR(12) NOT NULL, 
CHfiR(8) NOT NULL, 
NUMBER NOT NULL, 
NUMBER NOT NULL, 
CHBRC5) NOT NULL, 
INTEGER NOT NULL, 
NUMBER, 

CHfiR(l) NOT NULL, 
NUMBER NOT NULL, 
CHORCD NOT NULL, 
CHflR(l) NOT NULL, 
GHfiR(16) NOT NULL, 






Mili 


Ejemplo de gei'jí.'-j-i.-in c:V c:.¡ijo.c;• 


Arma hace clic en el botón Tables. "[Dale un vistazo a nuestra nueva tabla!", exclama 
Anna. Ella hace clic en la tabla SOFTWARE y en la vista diseño. "Aquí tienes nuestra estruc¬ 
tura de Visible Analyst, implementada en Microsoft Access." 

"Ahora se ve fenomenal", dice Chip con una amplia sonrisa. 

Los analistas siguen generando tablas hasta que finalizan el diseño. 

"Creo que podemos dejarle el resto a los programadores", comenta Anna. "Haríamos 
mejor en comenzar el desarrollo de los planes de prueba para cada programa." 

Los planes de prueba contienen detalles acerca de cómo determinar si los programas 
funcionan correctamente, y se los envían a Mack y Dee, quienes crearán los datos para las 
pruebas. En cada archivo de prueba que se utiliza en los programas por lotes se incluyen da¬ 
tos válidos e inválidos. Lo mismo ocurre con los sistemas interactivos, excepto que los datos 
de prueba se escriben en formas semejantes al diseño de las pantallas. Una vez que Mack 
termina de probar sus programas y se convence de que funcionan correctamente, reta a Dee 
a que encuentre algún error en los programas. A su vez, Dee le pide a Mack que pruebe sus 
programas en una especie de competencia amistosa. Ambos están conscientes de que los pro¬ 
gramadores no siempre detectan sus propios errores, porque conocen tanto sus propios 
programas que podrían ignorar errores sutiles de lógica. 
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EJERCICIOS 

E-l. Vea el diagrama de estructura PRODUCE SOFTWARE CROSS-REF REP. Haga do¬ 
ble clic en algunos módulos para ver sus entradas en el depósito. 

|P E-2. Modifique el diagrama de estructura PRODUCE HARDWARE INVESTMENT RPT. 

Agregue la función PRINT INVESTMENT LINE en el rectángulo vacío que se pro¬ 
porciona. PRINT HEADING LINES y WRITE REPORT LINE están subordinados a 
este módulo. Describa cada función en el depósito. 

E-3. Modifique el diagrama de estructura del archivo CHANGE COMPUTER. Incluya el 
símbolo de bucle y agregue los siguientes módulos subordinados al módulo 160, 
CHANGE COMPUTER RECORD (también vea abajo): 

A. SHOW CHANGE DISPLAY 

B. ACCEPT COMPUTER CHANGES 

C. VALÍDATE CHANGES 

D. DISPLAY ERROR MESSAGE 

E. CONFIRM CHANGES 

Los siguientes módulos deben subordinarse al módulo 220, PUT COMPUTER RE¬ 
CORD: 


A. FORMAT COMPUTER RECORD 

B. REWRITE COMPUTER RECORD 

ípf E-4. Modifique el diagrama de estructura ADD SOFTWARE RECORD agregando un 
símbolo de bucle y acoplando las conexiones. El siguiente acoplamiento se debe co¬ 
locar en la línea de conexión arriba de cada módulo (también vea abajo): 


A. Módulo: 

Pasado hacia arriba: 

B. Módulo: 

Pasado hacia arriba: 

C. Módulo: 

Pasado hacia abajo: 
Pasado hacia arriba: 

D. Módulo: 

Pasado hacia abajo: 
Pasado hacia arriba: 

E. Módulo: 

Pasado hacia abajo: 
Pasado hacia arriba: 

E Módulo: 

Pasado hacia abajo: 
G. Módulo: 

Pasado hacia abajo: 


DISPLAY ADD SOFTWARE SCREEN 
ADD SOFTWARE SCREEN 
ACCEPT ADD SOFTWARE SCREEN 
EXIT INDICATOR (Control) 

ADD SOFTWARE SCREEN DATA 
VA L Í D ATE ADD SOFTWARE DATA 
ADD SOFTWARE SCREEN DATA 
CANCEL TRANSACTION (Control) 

VA T. T D ADD SOFTWARE DATA 
READ SOFTWARE RECORD 
SOFTWARE INVENTORY NUMBER 
RECORD FOUND (Control) 

VALÍDATE HARDWARE REQUIREMENTS 
ADD SOFTWARE SCREEN DATA 
VA T. T D DATA (Control) 

ERROR MESSAGE 

DISPLAY ERROR MESSAGE 

ERROR MESSAGE 

PUT NEW SOFTWARE RECORD 

VA T. T D ADD SOFTWARE DATA 


Los ejercicios precedidos por un ¡cono Web indican que en el sitio Web del libro hay material de valor 
agregado. Los estudiantes pueden descargar una base de datos de Microsoft Access que pueden utilizar 
para completar los ejercicios. 
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H. Módulo: 

Pasado hacia abajo: 
Pasado hacia arriba: 

I. Módulo: 

Pasado hacia abajo: 


FORMAT SOFTWARE RECORD 
VALID ADD SOFTWARE DATA 
FORMATTED SOFTWARE RECORD 
WRITE SOFTWARE RECORD 
FORMATTED SOFTWARE RECORD 
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E-5. Elabore el diagrama de estructura PRINT PROBLEM MACHINE REPORT. A conti¬ 
nuación se da un esquema de los módulos, con cada módulo subordinado sangrado: 

PRINT PROBLEM MACHINE REPORT 
PRINT PROBLEM MACHINE LINES 
READ MACHINE RECORD 
DETERMINE PROBLEM MACHINE 
PRINT PROBLEM MACHINE LINE 
PRINT HEADING LINES 
WRITE REPORT LINE 
PRINT FINAL REPORT LINES 
WRITE REPORT LINE 

:||j| E-6. Elabore el diagrama de estructura CHANGE SOFTWARE RECORD. Los módulos 
del programa se muestran con sus módulos subordinados sangrados. 

CHANGE SOFTWARE FILE 

CHANGE SOFTWARE RECORDS 
GET SOFTWARE RECORD 

DISPLAY SOFTWARE ID SCREEN 
ACCEPT SOFTWARE ID SCREEN 
FIND SOFTWARE RECORD 
DISPLAY ERROR LINE 
OBTAIN SOFTWARE CHANGES 
DISPLAY CHANGE SCREEN 
ACCEPT SOFTWARE CHANGES 
VALÍDATE CHANGES 
DISPLAY ERROR LINE 
PUT SOFTWARE RECORD 

FORMAT SOFTWARE RECORD 
REWRITE SOFTWARE RECORD 

E-7. Elabore el diagrama de estructura SOFTWARE DETAILS INQUIRY Los módulos se 
enlistan con sus módulos subordinados sangrados. 

INQUIRE SOFTWARE DETAILS 
INQUIRE SOFTWARE RECORD 
GET SOFTWARE RECORD 

DISPLAY SOFTWARE ID SCREEN 
ACCEPT SOFTWARE ID SCREEN 
FIND SOFTWARE RECORD 
DISPLAY ERROR UNE 
DISPLAY INQUIRY SCREEN 

FORMAT SOFTWARE INQUIRY SCREEN 
DISPLAY SOFTWARE INQUIRY SCREEN 
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E-8. Vea el diagrama de flujo del sistema ADD COMPUTER. 

F.-9. Modifique el flujo del sistema ADD SOFTWARE. Agregue los siguientes rectángu¬ 
los del programa abajo del proceso manual INSTALL SOFTWARE. Incluya los archi¬ 
vos e informes de entrada y salida especificados para cada programa. 

Programa: UPDATE SOFTWARE RELATIONAL FILE 

Entrada: UPDATE SOFTWARE INSTALLATION LIST, documento 

UPDATE INSTALLED SOFTWARE SCREEN, pantalla 
Salida: SOFTWARE RELATIONAL FILE, disco 

INSTALLED SOFTWARE TRANSACTION, disco 
Programa: PRINT USER NOTIFICARON REPORT 

Entrada: INSTALLED SOFTWARE TRANSACTION, disco 

Salida: USER NOTIFICATION REPORT, informe 

E-10. Elabore el diagrama de flujo del sistema ADD STAFF. Hay dos programas: ADD 
STAFF y PRINT NEW STAFF LIST. La entrada para el programa ADD STAFF es un 
listado NEW STAFF y un pantalla de entrada ADD NEW STAFF. El archivo STAFF 
MASTER se actualiza* y se produce un nuevo archivo NEW STAFF LOG. Este últi¬ 
mo archivo es entrada para el programa PRINT NEW STAFF LIST, que produce el 
informe NEW STAFF LIST. 

E-l 1. Diseñe datos de prueba en papel para probar el programa ADD COMPUTER. Utili¬ 
ce Microsoft Access para probar la pantalla. Anote cualquier inconsistencia. 

E-l 2. Diseñe datos de prueba y resultados previstos para el programa ADD SOFTWARE. 
Utilice Microsoft Access para probar la pantalla y anote si los resultados se apegaron 
a sus predicciones. 

E-13. Diseñe datos de prueba y resultados previstos para el programa ADD TRAINING 
CLASS. Utilice Microsoft Access para probar la pantalla y anote si los resultados se 
apegaron a sus predicciones. 

E-14. Diseñe datos de prueba en papel para probar el programa CHANGE SOFTWARE 
EXPERT. Utilice Microsoft Access para probar la pantalla. Anote cualquier incon¬ 
sistencia. 
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OBJETIVOS DE APRENDIZAJE «./' ;íC ~ 

Una vez que haya dominado el material de este capitulo, podrá: 

1. 1 Comprender la implementación de una variedad de sistemas distribuidos. 

2. Diseñar programas de capacitación adecuados para los usuarios del nuevo sistema. 

3. Reconocer las diferencias entre las estrategias de conversión física y recomendar la. más apropiada 

a cada cliente. .V ' .' I'. 

•4.: Solucionar las preocupaciones de seguridad para los sistemas tradicionales y los basados en Web.. 

5. Entender la importancia de evaluar el nuevo sistema y recomendar la técnica de evaluación más 
> , conveniente a cada cliente :’L r< : ' 


'(ti privcso Jo iisi’JHiirar que el Mslorna de iiil'«rñi;inun es openirionnl y después permitir a los 
usuarios encardarse de su operación con Mués de uso y oWluación se denomina ¡mpiemen- 
iación.. Itl v.nnlisia cié sKIonus tiene arios enlbqiu-s jiara la ¡mplolnontación que se deben 
consider; 1 .-!" mientras se prepara el enrubio hacia el nuevo siMelna. Iridios enioquos incluyen 
el proporcionar más poiler de cómputo a los usuarios a través del procesamiento distribuí- : 
do ; capacitar a usuarios, conwrtir el sistema viejo V evaluar el nuevo. 

£.1 prime 1 " enlbc|ue para la implementación.involucra, el movimiento de pode de íómpu¬ 
to hacia los usuarios individuaíes al. establecer J’entregar el poder de la computadora y la 
ív-rionsabilldp.d por MI administración hacia K'up' .! a lo lar&o del neuocio con la ajuda del 
cómputo distribuido ■ ■ 

lü secundo enfoque para la implementación es usar dllcrentes estrategias para capaci¬ 
tar a usuarios y personal, usando una variedad de técnicas de capacitación y adirilrándose-' 
qtie cada usuario entienda cualquier papei nuevo que él o.clin deben asumir debido al nue¬ 
vo sistema de Información.. • 7. v, 

Otro enfoque para la implementación es esconer una estrategia de conversión, MI 
analista de sistemas necesita evaluar la situación y proponer un plan para pasar del .sisto- 
..ma anterior al'nuevo.que sea adecuado para la uryani ación y sistema de Información 
particulares. ■ .■ • ? 'í ¿-;■ í = -..Á'I 

ir uarto enfoque' para la. Implementación involucra evaluar el sNtonrJ de 'míormaclón. 
nuevo o el modificado, 1 71 anallstá necesita lormulár medidas de desempeño para evaluar i el- - 
sistema. Las evaluaciones vienen de los usuariodirección y analistas: ; 
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i P LE ME NT A C i M DE SISTEMAS DISTRIBUIDOS 

Si la confiabilidad de una red de telecomunicaciones es alta, es posible tener sistemas distri¬ 
buidos para los negocios, una disposición que se puede concebir como una aplicación de te¬ 
lecomunicaciones. El concepto de sistemas distribuidos se usa de muchas formas diferentes. 
Aquí se tomará en un sentido amplio para que incluya estaciones de trabajo que se pueden 
comunicar entre sí y con los procesadores centrales, así como también diferentes configura¬ 
ciones arquitectónicas jerárquicas de procesadores de datos que se comunican entre sí y que 
tiene diferentes capacidades de almacenamiento de datos. 

El modelo de arquitectura de información que probablemente dominará el sistema de 
redes en los próximos años es el cliente/servidor. En este modelo, las funciones del proce¬ 
samiento se delegan ya sea a los clientes (usuarios) o a los servidores, dependiendo de qué 
máquinas son más convenientes para ejecutar el trabajo. En este tipo de arquitectura, la 
parte del cliente de una aplicación de red se ejecutará en el sistema del cliente, con la par¬ 
te del servidor de la aplicación que se ejecuta en el servidor de archivos. Con un modelo 
cliente/servidor, los usuarios interactúan con las partes limitadas de la aplicación, incluyen¬ 
do la interfaz de usuario, entrada de datos, consultas de base de datos y generación de 
reportes. El control de acceso de usuario a las bases de datos centralizadas, recuperar o pro¬ 
cesar datos y otras funciones (tal como administrar dispositivos periféricos) se manejan por 
el servidor. 

TECNOLOGÍA CLIENTE/SERVIDOR 

El modelo cliente/servidor (C/S), la computación cliente/servidor, la tecnología cliente/ 
servidor y la arquitectura cliente/servidor se refieren a un modelo de diseño que se puede 
pensar como aplicaciones que se ejecutan en una red de área local (LAN). En términos 
muy básicos, puede describir que el cliente solicita —y que el servidor ejecuta o de alguna 
forma realiza— las solicitudes de trabajo. Las computadoras en la red se programan para 
desempeñar eficazmente el trabajo dividiendo las tareas de procesamiento entre clientes y 
servidores. La figura 17.1 muestra cómo se podría configurar un modelo cliente/servidor 
con una LAN. Observe que varios "clientes" se describen como estaciones de trabajo del 
usuario. 

Cuando piensa en el modelo cliente/servidor, debe pensar en un sistema que coloca a 
los usuarios como el centro del trabajo, con su interacción con datos que son el concepto 
clave. Aunque hay dos elementos funcionando —el cliente y el servidor— el objetivo del 
modelo C/S es que los usuarios lo vean como un sistema. De hecho, se espera que los usua¬ 
rios no adviertan cómo desempeña la red cliente/servidor su procesamiento distribuido, de¬ 
bido a que debe tener la apariencia de un sistema unificado. En una red de igual a igual, las 
PCs pueden actuar como el servidor o el cliente, dependiendo de los requerimientos de 
la aplicación. 

Clientes como parte del modelo C/S que usa una LAN Cuando ve el término cliente, po¬ 
dría pensar en personas o usuarios; por ejemplo, hablamos de "clientes de nuestra práctica 
de consultoria". Sin embargo, en el modelo C/S el término cliente no se refiere a las personas, 
sino a máquinas conectadas a la red que son sitios típicos de entrada al sistema cliente/ser¬ 
vidor que se usa por los humanos. Por lo tanto, los clientes podrían ser computadoras de es¬ 
critorio conectadas a la red, una estación de trabajo o computadoras portátiles o cualquier 
otra forma en que el usuario puede entrar al sistema. 

Al usar una interfaz gráfica de usuario (GUI), los individuos normalmente interactúan 
en forma directa sólo con la parte del cliente. Las estaciones de trabajo del cliente usan pro¬ 
gramas más pequeños que residen en el cliente para hacer el procesamiento en primer plano 
(contrario al procesamiento en segundo plano, mencionado más adelante), incluyendo co¬ 
municación con el usuario. Si una aplicación se denomina aplicación basada en el cliente, la 
aplicación reside en una computadora cliente y no se puede acceder por otros usuarios en 
la red. Observe que las aplicaciones basadas en el cliente requieren una instalación separa¬ 
da en cada estación de trabajo si la LAN no ha comprado una licencia de sitio. 
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SERVIDOR 


Servidor de archivos. El senador de archivos es el término que denota una computado¬ 
ra en una LAN que almacena en su disco duro los programas de aplicación y los archivos de 
datos para todos los clientes en la red. Las aplicaciones basadas en el servidor son tipos 
de capacidades de procesamiento del cliente que permiten al usuario solicitar las aplicacio¬ 
nes de la red (programas almacenados en un servidor de red en lugar de en la computadora 
de un usuario) del servidor. El procesamiento en segundo plano (por ejemplo, tal como una 
búsqueda física de una base de datos) con frecuencia tendrá lugar en un servidor. Si un ser¬ 
vidor de archivos falla, las aplicaciones basadas en el cliente no se afectan. 


Cumlgufcluon de. un. sistema . 
:..cliente/servidor. ' 













El diseño de una red cliente/servidor es una forma de asignar los recursos en una LAN 
para distribuir el poder de cómputo entre las computadoras de la red. Sin embargo, observe 
que aún tiene sentido compartir algunos recursos, los cuales se pueden centralizar en un 
servidor de archivos. Las redes cliente/servidor están demostrando ser una buena forma de 
incluir las aplicaciones de grupos de trabajo. 

Servidor de impresión. Un servidor de impresión en una LAN es accesible para todas 
las estaciones de trabajo. A diferencia de un servidor de archivos, un servidor de impresión 
es una PC dedicada a recibir y (temporalmente] almacenar archivos para ser impresos. El 
software especializado que el servidor de impresión usa primero le permite almacenar tra¬ 
bajos de impresión y después le ayuda a administrar la distribución de tareas de impresión 
en las impresoras conectadas a la red. 

Aunque parece como si fueran los mismos que los servidores de impresión y los servi¬ 
dores de archivos, los servidores Web son el software, no una combinación de software y 
hardware como lo son los servidores de impresión y los servidores de archivos. Consulte la 
sección de diseño de sitios Web en el capítulo 11 para más información sobre las aplicacio¬ 
nes Web. 


Análisis de las ventajas y desventajas del modelo C/S Aunque muchas compañías rápida¬ 
mente solicitaron sistemas cliente/servidor, la experiencia de los primeros en adoptarlos in¬ 
dica que no siempre son la mejor solución a los problemas informáticos de la organización. 
Con frecuencia, se pide al diseñador de sistemas que avale un modelo C/S que ya está en 
funcionamiento. Así como con cualquier otra propuesta de cómputo corporativa en cuya 
creación usted no haya tenido una parte activa, debe revisar el plan cuidadosamente. ¿La 
cultura de la organización apoyará un modelo C/S? ¿Qué cambios se deben hacer en la cul¬ 
tura informal y en los procedimientos de trabajo formales para que un modelo C/S se 
pueda usar a toda su capacidad? ¿Cuál debe ser su papel como analista de sistemas en esta 
situación? 

Aunque uno de los beneficios mencionados del modelo C/S son los costos más bajos 
del procesamiento, hay muy pocos datos reales disponibles para demostrarlo (aun cuando 
hay alguna evidencia anecdótica para apoyar esta aseveración). Hay costos de cambio y cos¬ 
tos iniciales sumamente bien documentados asociados con una migración hacia una arqui¬ 
tectura C/S. Las aplicaciones para el modelo C/S se deben escribir como dos componentes 
de software separados, cada uno corriendo en máquinas separadas, pero deben aparecer co¬ 
mo si operaran como una aplicación. El modelo C/S es más caro que otras opciones que 
usan terminales, en lugar de computadoras personales, para acceder a computadoras remo¬ 
tas. Sin embargo, usar el modelo C/S permite usar mayor poder de cómputo y brinda una 
mejor oportunidad de personalizar las aplicaciones. 

Sin el apoyo y la estructura organizacional requeridos para comprender el potencial de 
poner la autoridad de la toma de decisiones al nivel del usuario, y por consiguiente más cer¬ 
ca de los clientes, este beneficio no tiene sentido. 
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TIPOS DE REDES DE SISTEMAS DISTRIBUIDOS 

Aunque las redes se pueden caracterizar por su forma o topología, también se discuten por 
lo que se refiere a su alcance geográfico y a los tipos de servicios que ofrecen. Los tipos es¬ 
tándares de redes incluyen una red de área amplia (WAN) y una red de área local (LAN). 
Las redes de área local son estándares para vincular computadoras locales o terminales en 
un departamento, edificio o varios edificios de una organización. Las redes de área amplia 
pueden servir a los usuarios por varias millas o a través de continentes enteros. Hay cuatro 
tipos principales de redes de sistemas distribuidos: jerárquica, estrella, anillo y bus. Cada 
uno requiere diferente hardware y software y tiene capacidades diferentes. 

Ahora conectar una red también es técnica, económica y operacionalmente factible pa¬ 
ra las oficinas pequeñas y proporciona una solución que los analistas deben considerar para 
los negocios pequeños. El equipo de una red a veces se denomina redes en una caja, debido 
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¡No, no estoy equipada con una conexión de módeml" 


a que todo lo necesario para establecer una red pequeña se proporciona a un precio (nor¬ 
malmente inferior a 300 dólares). Un ejemplo de dicho equipo incluye adaptadores para 
PCs, un hub de ocho puertos y una buena cantidad de cableado. A veces, en estos paquetes 
también se incluyen hojas de cálculo para ayudarle a diseñar la instalación de la red. 

Una conexión de red proporciona ventajas para negocios pequeños cuando uno conside¬ 
ra la posibilidad de compartir software y la mejora de trabajo de grupo. También, los nego¬ 
cios pequeños podrían invertir en una impresora de mejor calidad, unidades de CD-ROM, 
módems u otros periféricos, debido a que necesitan menos de ellos cuando los usuarios 
pueden compartir los recursos en la red. La mayoría de equipos de red excluyen el softwa¬ 
re de sistema operativo de red y esta posibilidad permite flexibilidad a negocios pequeños al 
usar cualquiera que se ajuste a sus requerimientos. 

Uno de los aspectos costosos de implementar una LAN es que cada vez que se mueve, 
se debe cambiar la instalación eléctrica. Algunas organizaciones están afrontando esto al es¬ 
tablecer una red inalámbrica de área local (WLAN) de alta velocidad. Más concreto, estas 
redes inalámbricas se denominan Wi-Fi (por fidelidad inalámbrica) o alternativamente 
estándar de red 802.1 Ib o tasa alta 802.11, que indican una LAN inalámbrica de alta velo¬ 
cidad que puede transmitir hasta 11 Mbps en un área de 100 metros. (Sin embargo, las ve¬ 
locidades de transmisión reales son más bajas cuando se usa la encripción que brindaría una 
privacidad equivalente al cableado, o WEP, para propósitos de seguridad.) 

Las WLANs son relativamente baratas de establecer y sirven como una tecnología fle¬ 
xible para apoyar los grupos de trabajo. Las redes inalámbricas también pueden proporcio¬ 
nar acceso a Internet móvil si las PCs y otros dispositivos están equipados con adaptadores 
y están dentro de 100 metros de un punto de acceso. Las zonas activas o puntos de acceso 
son redes Wi-Fi que están disponibles en ciertas ubicaciones de alta circulación de Internet, 
tal como los dormitorios de una universidad, bibliotecas, asociaciones de aerolíneas y hote¬ 
les, así como también en algunos lugares públicos improbables, tal como las áreas del Cen¬ 
tral Park, en la ciudad de Nueva York, y varias cafeterías en Irlanda. Algunos de éstos son 
puntos de acceso patrocinados comercialmente y otros están patrocinados por las comuni¬ 
dades locales y municipales para proporcionar acceso gratuito a Internet. 

Aunque ésta es una alternativa económica cada vez más popular, hay preocupacio¬ 
nes respecto a su seguridad así como también respecto a la integridad de la señal, debido 
a que las redes Wi-Fi son propensas a la interferencia de sistemas que operan cerca en el 


IMPLEMENTACION EXITOSA DEL SISTEMA DE INFORMACION 


(irálHH.1 («. B25 





mismo número de frecuencia. Desafortunadamente, no hay ninguna forma de detener 
o limitar cualquier nuevo dispositivo adicional en el área, y esto puede aumentar la in¬ 
terferencia. 

Para mejorar la seguridad de transmisión de datos, Wi-Fi usa WEP, el cual es el estándar 
de encriptación opcional 802.11 que la mayoría de las tarjetas de interfaz de red (NIC] de 
radio y los vendedores de punto de acceso apoyan. Se han descubierto muchas fallas, pero 
usado en conjunto con las medidas tradicionales de seguridad de LAN, se piensa que WEP 
es adecuado para muchos propósitos caseros y de negocio. 

Otro tipo de estándar de conexión de red inalámbrica es Bluetooth. Más conveniente 
para redes personales pequeñas, Bluetooth incorpora una gran variedad de dispositivos in¬ 
cluyendo computadoras, impresoras, dispositivos portátiles, teléfonos, teclados, ratones y 
dispositivos caseros. 

Redes jerárquicas En una configuración jerárquica básica, el host —un mainframe— con¬ 
trola todos los nodos, los cuales pueden incluir minicomputadoras y PCs. Observe que las 
computadoras en el mismo nivel no se comunican entre sí. Con esta configuración, los pro¬ 
blemas informáticos complejos se manejan por el mainframe y los problemas informáticos 
menores se manejan por las minicomputadoras o por las PCs. 

Redes de estrella Otra configuración popular para la computación distribuida es la red de 
estrella. Un mainframe, PC o estación de trabajo se designa como el nodo central. Como tal, 
se comunican con los nodos menores, pero no se pueden comunicar directamente entre sí. 
Si se requiere que las PCs se comuniquen entre sí, se lograría con una PC enviando datos al 
nodo central, el cual pasaría los datos a la segunda PC. 

Redes de anillo Estas son otra posibilidad para la computación distribuida. No hay ningu¬ 
na computadora central para un anillo. Más bien, su forma nos recuerda que todos los nodos 
tienen la misma capacidad de cómputo. Con el uso de una red de anillo, todas las PCs se 
pueden comunicar directamente entre sí, pasando todos los mensajes que leyeron a sus des¬ 
tinos correctos en el anillo. 

Configuraciones de bus Otro tipo de red para el procesamiento distribuido es la configu¬ 
ración bus. Las configuraciones bus trabajan bien en cuartos cerrados, tal como en un con¬ 
junto de oficinas donde varios dispositivos diferentes se pueden conectar usando un cable 
central. Una configuración bus permite hacer cambios de forma sencilla, pudiendo agregar 
o quitar dispositivos muy fácilmente. En esta configuración, un único cable central sirve co¬ 
mo la vía de comunicación. 
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MODELADO DE REDES 

Debido a que la conexión a una red se ha vuelto muy importante, el diseñador de sistemas 
necesita tomar en cuenta al diseño de la red. Ya sea que un diseñador de sistemas tenga que 
elegir entre redes token ring o Ethernet —o si se preocupa por el hardware tal como enru- 
tadores y puentes que deben estar en el lugar cuando se conocen las redes—, siempre de¬ 
be tomar en cuenta el diseño lógico de las redes. Aquí es donde entra enjuego el modela¬ 
do de redes. 

Las herramientas CASE como Visible Analyst no son suficientes para ayudar al diseña¬ 
dor de sistemas con el modelado de redes. Es posible usar alguna de las habilidades de dibu¬ 
jo de una herramienta CASE, pero forzar las herramientas de modelado de datos para hacer 
modelado de redes no funciona. Por lo tanto, sugerimos usar un conjunto de símbolos tal 
como los de la figura 17.2 para modelar la red. Es útil tener diferentes símbolos para distin- 
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Use símbolos especiales al 
dibujar descomposición de relés 
y diagramas de conectividad de' ! 
t hub. 1 


guir entre los hubs, redes externas y estaciones de trabajo. También es útil adoptar una con¬ 
vención para ilustrar múltiples redes y estaciones de trabajo. 

Normalmente, un enfoque descendente es apropiado. El primer paso es dibujar un dia¬ 
grama de descomposición de red que proporcione una apreciación global del sistema. Des¬ 
pués, dibujar un diagrama de conectividad de hub. Finalmente, dividir el diagrama de co- 
nectividad de hub para mostrar las diversas estaciones de trabajo y cómo se conectan. 

Dibujando un diagrama de descomposición de red Podemos ilustrar el dibujo de un mo¬ 
delo de descomposición de red al referirnos una vez más al ejemplo de World's Trend Cata- 
log División de los capítulos anteriores. Empiece dibujando un círculo en la parte superior 
y nombrándolo como "Red de World's Trend". Como se muestra en la figura 17.3, dibuje 
varios círculos en el nivel inferior. Estos círculos representan los hubs para la división de 
marketing y para cada uno de los tres centros de toma de pedidos y distribución (división 
americana, división canadiense y división mexicana). 

Podemos extender este dibujo al dibujar otro nivel. Esta vez, podemos agregar las 
estaciones de trabajo. Por ejemplo, la división de marketing tiene dos estaciones de tra¬ 
bajo conectadas, mientras que la división americana tiene 33 estaciones de trabajo en su 
LAN (administración, almacén, gerente de entrada de pedido y 30 empleados de entrada 
de pedido). Esta red se simplifica con el propósito de proporcionar un ejemplo fácil de 
entender. 

Creación de un diagrama de conectividad de hub El diagrama de conectividad de hub 
es útil para mostrar cómo se conectan los hubs principales. En World's Trend (véase la fi¬ 
gura 17.4), hay cuatro hubs principales conectados entre sí. Además, hay hubs externos 
(proveedores) que necesitan ser notificados cuando el nivel de inventario baja a un cierto 
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Diagrama de descomposición 
de red para World's Trend. 



punto, etc. Cada una de las tres divisiones de país se conecta a los 21 proveedores; sin em¬ 
bargo, la división de marketing no necesita ser conectada a los proveedores. 

Para producir un diagrama de conectividad de hubs eficaz, empiece dibujando todos 
los hubs. Después experimente (quizás haciendo primero un bosquejo en una hoja de pa¬ 
pel) para ver qué vínculos son necesarios. Una vez hecho esto, puede volver a dibujar el dia¬ 
grama para que sea atractivo y comunique bien a los usuarios. 



Diagrama de conectividad de 
nodos para World's Trend. 
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División del diagrama de conectividad de hubs en un diagrama de conectividad de estacio¬ 
nes de trabajo El propósito del modelado de redes es mostrar la conectividad de estaciones 
de trabajo con un cierto nivel de detalle. Para ello, dividimos el diagrama de conectividad de 
hubs. La figura 17.5 muestra cada una de las 33 estaciones de trabajo para la división ame¬ 
ricana y cómo se conectan. 

Dibuje los diagramas para este nivel examinando el tercer nivel del diagrama de des¬ 
composición de red. Agrupe los artículos tal como Gerente de entrada de pedido y Em¬ 
pleados de entrada de pedido, debido a que ya reconoce que se deben conectar. Use un 
símbolo especial para mostrar múltiples estaciones de trabajo e indique en paréntesis el 
número de estaciones de trabajo similares. En nuestro ejemplo, hay 30 empleados de entra¬ 
da de pedido. 

En el perímetro del diagrama, coloque estaciones de trabajo que se deben conectar a 
otros hubs. De esta forma, será más fácil representar estas conexiones usando flechas. Dibu¬ 
je las conexiones externas en un color diferente o use flechas más gruesas. Las conexiones 
externas normalmente están a grandes distancias. Por ejemplo, la administración se conecta 
a la división de marketing, la cual está a 50 millas, y también a las divisiones canadiense y 
mexicana. El almacén necesita comunicarse directamente con los almacenes canadiense 
y mexicano en caso de que sea posible obtener la mercancía de otro almacén. El gerente de 
entrada de pedido y los empleados de entrada de pedido no tienen que estar conectados con 
nadie fuera de su LAN. 

Los diagramas de conectividad de hubs se pueden dividir en muchos niveles. Si hacer 
esto tiene sentido en su aplicación particular, prosiga y dibújelos de esa forma. No hay nin¬ 
gún límite al posible número de divisiones. 

Los diagramas de conectividad de hubs y de conectividad de estaciones de trabajo tam¬ 
bién se pueden dibujar usando paquetes de software. Aunque sería difícil si se limita a usar 
software de herramienta CASE, es relativamente simple si usa software flexible de arrastrar 
y colocar, tal como Microsoft Visio. (Véase la figura 17.6.} 

Visio incluso contiene dibujos que describen ciertas partes del equipo, si desea entrar 
en detalles. Al usar dibujos específicos, un analista podría arrastrar cada símbolo de la plan¬ 
tilla al pedazo de papel. La figura 17.7 muestra cómo se establecen dos redes para un fabri¬ 
cante de software. La parte superior de la figura ilustra la red del sector de desarrollo del 
programa de la organización y la parte inferior muestra la red del departamento de ventas. 
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Los analistas pueden dibujar 
diagramas de conectividad 
de nodos usando software como : 
Visio Professional. 
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Los paquetes tal como Visio son sumamente útiles para el analista de sistemas debido a que 
ahorran tiempo y mejoran la comunicación al usar símbolos estándar. 


GROUPWARE 

La escritura de aplicaciones, si es para una organización entera o para un tomador de deci¬ 
siones independiente, también ha cambiado dramáticamente. Debido a que actualmente 
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Diagrama mas detallado de dos 
redes, dibujado al seleccionar 
símbolos de una plantilla y 
colocarlos en el pedazo 
de papel. Este diagrama se dibujó 
usando Visio Professional de 
Visio Corporation. 































































mucho del trabajo de la organización se realiza en grupos o equipos, ahora está en marcha 
un movimiento poderoso denominado groupware para desarrollar software especial que 
apoya a las personas que trabajan juntas en la organización. El groupware toma ventaja de 
las sinergias potenciales y del poder disponible de las PCs conectadas a redes LANs o WANs, 
o a Web. Los productos del groupware pueden ayudar a los miembros de un grupo a fijar y 
asistir a reuniones, compartir datos, crear y analizar documentos, comunicarse entre sí de 
formas no estructuradas mediante correo electrónico, sostener conferencias de grupo y ma¬ 
nejar y supervisar el flujo de trabajo. 

Aunque la mayoría de las compañías de software está de acuerdo sobre la importancia 
de apoyar el trabajo en grupo, difieren en lo que los grupos y personas individuales necesi¬ 
tan para el apoyo. Por ejemplo, actualmente Novell ofrece características de groupware ta¬ 
les como correo electrónico, mensajería y calendarización en un entorno conectado a una 
red. En el futuro, el software apoyará a los usuarios permitiéndoles armar un informe que 
contiene objetos recopilados en cualquier parte de la red, sin importar qué sistemas se usa¬ 
ron para crearlos. Por lo tanto, un informe podría tener texto del informe anual, gráficos de 
barras de la última semana de ventas encontradas e imágenes escaneadas de bocetos dibuja¬ 
dos a mano que describen la última sesión de generación de ideas del departamento. En tal 
caso, la computadora buscaría varias partes y el software las coordinaría para usarlas en un 
documento. 

Otro enfoque para desarrollar el groupware se ha tomado de Microsoft, el cual propor¬ 
ciona capacidades rudimentarias de grupos de trabajo para productos tales como Windows 
para Workgroups y Windows NT. Las interfaces gráficas de usuario incluyen un almacén de 
objetos para que los sistemas operativos de Microsoft tengan incorporadas las capacidades 
del grupo de trabajo. A corto plazo, Microsoft está trabajando con diseñadores pequeños y 
consultores para desarrollar soluciones de aplicación del grupo de trabajo. Este enfoque as¬ 
cendente también parece estar mostrando resultados exitosos. Diferentes herramientas de 
groupware ofrecen tipos diferentes de apoyo. 

Ventajas de los sistemas distribuidos Los sistemas distribuidos permiten el almacena¬ 
miento de datos en lugares donde no estorben a las transacciones de tiempo real en línea. 
Por ejemplo, el tiempo de respuesta en las consultas se podría mejorar si no todos los re¬ 
gistros necesitan ser investigados antes de que se dé una respuesta. Además, los usuarios no 
necesitan los datos todo el tiempo, de modo que se pueden almacenar en medios menos 
caros en un sitio diferente y se pueden acceder sólo cuando sea necesario. 

El uso de sistemas distribuidos también puede bajar los costos de equipo, debido a que 
no todas las partes del sistema necesitan desempeñar todas las funciones. Se pueden com¬ 
partir algunas habilidades, tal como procesamiento y almacenamiento. 

Los sistemas distribuidos también pueden ayudar a bajar los costos permitiendo flexi¬ 
bilidad en la opción del fabricante, debido a que el enfoque total de redes está en comuni¬ 
car entre nodos y los fabricantes hacen los componentes compatibles. Esta compatibilidad 
permite al usuario comprar por el precio así como también por la funcionalidad. Además, al 
principio, los sistemas distribuidos pueden ser menos caros que los sistemas grandes porque 
es posible diseñar para la expansión sin realmente tener que comprar el hardware en el mo¬ 
mento que el sistema se implementa. El desarrollo de intranets corporativas es una forma 
preventiva de conectar a una red a los miembros organizacionales, una forma que también 
puede servir como un medio para reducir los aspectos problemáticos de Internet [tal como 
navegar sin objeto por Internet en horas de oficina o posibles fallas de seguridad causadas 
por la falta d efirewalls] y al mismo tiempo apoyo al trabajo de grupo con aplicaciones útiles. 
Las extranets formadas con proveedores y otros socios importantes también son excelentes 
formas de demostrar que un negocio está orientado hacia el exterior y es accesible. En la fi¬ 
gura 17.8 se dan ventajas de los sistemas distribuidos. 


Desventajas de los sistemas distribuidos Los sistemas distribuidos presentan algunos 
problemas únicos que los sistemas de cómputo centralizados no poseen. El analista necesi- 
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ta pesar estos problemas contra las ventajas presentadas y plantearlos también con el nego¬ 
cio interesado. 

El primer problema es la confiabilidad de la red. Para hacer de una red un recurso en 
lugar de una carga, debe ser posible transmitir, recibir, procesar y almacenar datos de forma 
confiable. Si hay demasiados problemas con la confiabilidad del sistema, éste se abandonará. 

La distribución de gran poder informático a individuos incremente la amenaza a la se¬ 
guridad debido al acceso extendido. La necesidad de contraseñas confidenciales, salas de 
cómputo seguras y capacitación de seguridad adecuada al personal son asuntos que se mul¬ 
tiplican cuando se implementan los sistemas distribuidos. 

Los analistas de sistemas que crean sistemas distribuidos necesitan enfocarse en la 
red o en el aspecto coordinado de los sistemas distribuidos. Su poder reside en su habili¬ 
dad de interactuar como grupos de trabajo del usuario que comparten datos. Si la rela¬ 
ción entre los subsistemas se ignora o se le resta importancia, está creando más problemas 
de los que está resolviendo. En la figura 17.9 se mencionan las desventajas de los siste¬ 
mas distribuidos. 


CAPACITACIÓN DE USUARIOS 

Los analistas de sistemas participan en un proceso educativo con los usuarios que se deno¬ 
mina capacitación. El usuario se ha involucrado en el ciclo de vida de desarrollo de sistemas 
por lo que ahora, el analista deba tener una valoración exacta de los usuarios que se deben 
capacitar. Como hemos visto, los centros de información tienen instructores propios. 

En la implementación de proyectos grandes, el analista normalmente estará manejando 
la capacitación en lugar de estar involucrado personalmente en ella. Uno de los recursos 
más valiosos que el analista puede aportar en cualquier situación de capacitación es la habi¬ 
lidad de ver el sistema desde el punto de vista del usuario. El analista nunca debe olvidar lo 
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que es enfrentar un nuevo sistema. Esas recopilaciones pueden ayudar a analistas a identifi¬ 
carse con los usuarios y pueden facilitar su capacitación. 


ESTRATEGIAS DE CAPACITACIÓN 

Los factores que determinan la estrategia de capacitación son las personas que serán capaci¬ 
tadas y quiénes las capacitarán. El analista tendrá que garantizar que cualquiera cuyo trabajo 
sea afectado por el nuevo sistema de información sea propiamente capacitado por el ins¬ 
tructor correcto. 

A quién capacitar Todas las personas que tendrán uso principal o secundario del sistema 
deben recibir capacitación. Esto incluye a todos, desde el personal de entrada de datos 
hasta aquellos que usarán la salida para tomar decisiones sin usar personalmente una 
computadora. La cantidad de capacitación que requiere un sistema depende de cuánto 
cambiará el trabajo de alguien debido al nuevo sistema. 

Debe asegurarse de que los usuarios con diferentes niveles de habilidad e intereses de 
trabajo estén separados. Habrá problemas si incluye a principiantes en las mismas sesiones 
de capacitación que los expertos, debido a que los principiantes se pierden con rapidez y los 
expertos se aburren con los elementos básicos. En consecuencia, ambos grupos se pierden. 

Personas que capacitan a los usuarios Para un proyecto grande, se podrían usar muchos 
instructores diferentes dependiendo de cuántos usuarios se deben capacitar y quiénes son. 
Las posibles fuentes de capacitación incluyen lo siguiente: 

1. Vendedores. 

2. Analistas de sistemas. 

3. Instructores externos. 

4. Instructores internos. 

5. Otros usuarios del sistema. 

Esta lista tan sólo proporciona algunas de las opciones que el analista tiene para diseñar y 
proporcionar la capacitación. 

Con frecuencia, los vendedores grandes proporcionan uno o dos días de sesiones de ca¬ 
pacitación sobre su equipo como parte de los beneficios de servicio ofrecidos cuando las 
corporaciones compran software comercial caro. Estas sesiones incluyen conferencias y ca¬ 
pacitación práctica en un entorno específico. 

Debido a que los analistas de sistemas conocen a las personas y al sistema de la organi¬ 
zación, con frecuencia pueden proporcionar buena capacitación. El uso de analistas para los 
propósitos de capacitación depende de su disponibilidad, debido a que también se espera 
que vigilen el proceso de implementación completo. 

En ocasiones la organización contrata instructores externos para colaborar en la capa¬ 
citación. Estos instructores externos podrían tener gran experiencia en capacitar a las per¬ 
sonas en cómo usar una variedad de computadoras, pero podrían no dar la capacitación 
práctica que algunos usuarios necesitan. Además, tal vez no tengan la capacidad de perso¬ 
nalizar suficientemente sus presentaciones para hacerlas significativas para los usuarios. 

Los instructores internos de tiempo completo con frecuencia están familiarizados con 
el personal y pueden adaptar los materiales a sus necesidades. Una de las desventajas de los 
instructores internos es que podrían tener experiencia en áreas aparte de los sistemas de in¬ 
formación y por consiguiente podrían carecer de profundidad en experiencia técnica que 
los usuarios requieren. 

También es posible asignar a cualquiera de estos instructores para que capacite a un 
grupo pequeño de personas de cada área funcional que estará usando el nuevo sistema de 
información. A su vez, estas personas se pueden usar para capacitar al resto de los usuarios. 
Este enfoque puede funcionar bien si los aprendices originales todavía tienen acceso a los 
materiales e instructores como recursos cuando ellos mismos proporcionen la capacita¬ 
ción. De lo contrario, esto podría acabar como una situación de prueba y error en lugar de 
una estructurada. 
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UNEAMIENTOS PARA LA CAPACITACIÓN 

El analista tiene cuatro lineamientos principales para establecer la capacitación. Éstos son 
(1] establecer objetivos medibles, (2) usar métodos de capacitación apropiados, (3) selec¬ 
cionar sitios de capacitación convenientes y (4) emplear materiales de capacitación en¬ 
tendióles. 

Objetivos de la capacitación Quien está siendo capacitado dicta, en gran medida, los ob¬ 
jetivos de la capacitación. Los objetivos de capacitación para cada grupo se deben explicar 
claramente. Los objetivos bien definidos son de gran ayuda permitiendo a los aprendices sa¬ 
ber lo que se espera de ellos. Además, los objetivos permiten evaluación de capacitación 
cuando están completos. Por ejemplo, los operadores deben saber dichos elementos esencia¬ 
les como encender la máquina, qué hacer cuando ocurren errores comunes, solucionar pro¬ 
blemas de elementos esenciales y cómo acabar un proceso de entrada. 

Métodos de capacitación Cada usuario y operador necesitarán capacitación ligeramente 
diferente. Hasta cierto punto, sus trabajos determinan lo que necesitan saber y sus persona¬ 
lidades, experiencia y antecedentes determinan cómo aprenden mejor. Algunos usuarios 
aprenden mejor viendo, otros oyendo e incluso otros haciendo. Debido a que normalmente 
no es posible personalizar la capacitación para un individuo, una combinación de métodos 
es a menudo la mejor forma de proceder. Así, la mayoría de los usuarios se atrae mediante 
un método u otro. 

Los métodos para aquellos que aprenden mejor viendo incluyen demostraciones de 
equipo y exposición para manuales de capacitación. Aquellos que aprenden mejor oyendo 
se beneficiarán de las conferencias sobre los procedimientos, discusiones y sesiones de pre¬ 
guntas y respuestas entre instructores y aprendices. Aquellos que aprenden mejor haciendo 
necesitan experiencia práctica con el nuevo equipo. Para trabajos como operador de compu¬ 
tadora, la experiencia práctica es esencial, mientras que un gerente de control de calidad 
para una línea de producción sólo podría necesitar ver la salida, aprender a interpretarla y 
saber cuándo se espera que llegue. 

Sitios de capacitación La capacitación se hace en muchas ubicaciones diferentes, algunas 
de las cuales son más favorables para aprender que otras. Los grandes vendedores de cómpu¬ 
to proporcionan ubicaciones remotas especiales en donde se mantiene equipo operable en 
forma gratuita. Sus instructores ofrecen experiencia práctica así como también seminarios 
en situaciones que permiten a los usuarios concentrarse en aprender el nuevo sistema. Una 
de las desventajas de la capacitación remota es que los usuarios están fuera del contexto or- 
ganizacional en el cual eventualmente se deben desempeñar. 

La capacitación en las instalaciones de la organización a la cual pertenecen los usuarios 
también es posible con varios tipos diferentes de instructores. La ventaja es que los usua¬ 
rios ven el equipo tal como estará cuando sea totalmente operacional. Una desventaja seria 
es que los aprendices con frecuencia se sienten culpables de no cumplir sus tareas rutinarias 
de trabajo si permanecen en el lugar de la capacitación. En estos casos, no se puede lograr 
una total concentración en la capacitación. 

Los sitios de capacitación remota también están disponibles mediante un pago a través 
de consultores y vendedores. Los sitios de capacitación se pueden establecer en lugares que 
alquilan espacios para reuniones, tal como un hotel, o incluso podrían ser instalaciones 
permanentes mantenidas por los instructores. Estos arreglos permiten a los trabajadores li¬ 
berarse de las demandas regulares del trabajo, pero no podrían proporcionar equipo para la 
capacitación práctica. 

Materiales de capacitación En la planeación de capacitación de usuarios, los analistas de 
sistemas deben comprender la importancia de los materiales de capacitación bien prepara¬ 
dos. Estos materiales incluyen manuales de capacitación; casos de capacitación, en los 
cuales los usuarios se asignan para trabajar a través de un caso que incluye la mayoría de 
las interacciones normalmente encontradas con el sistema, y prototipos y muestras de sali¬ 
das. Los usuarios de sistemas grandes a veces se podrán capacitar en simulaciones detalladas 
basadas en Web o software que es idéntico a lo que se escribe o se compra. La mayoría de 













Gí cócrtr- fegasVíe 
:'' ¡safa te-s Bte’li'í«v¿fe. ¡i' ionicé h. 


Método de conversión Cambios a través del tiempo 


Conversión directa .|j 

Conversión paralela 


Conversión gradual 


Conversión de prototipo 
modular 




Jane .vr':: ¿jáOkJkLkh iMJgfll 



Conversión distribuida 


pre la más apropiada para proceder con la conversión. La importancia de diseñar y progra¬ 
mar adecuadamente la conversión (la cual con frecuencia tarda muchas semanas), archivo 
de respaldo y la seguridad adecuada no se pueden subestimar. 

ESTRATEGIAS DE CONVERSIÓN 

En la figura 17.11 se presentan las cinco estrategias para convertir del sistema viejo al nue¬ 
vo y son como sigue: 

1. Conversión directa. 

2. Conversión paralela. 

3. Conversión gradual o por fases. 

4. Conversión de prototipo modular. 

5. Conversión distribuida. 

Cada uno de los cinco enfoques de conversión se describe por separado en las siguientes 
subsecciones. 

Conversión directa La conversión directa significa que en una fecha especificada, el sistema 
viejo se abandona y el nuevo sistema se pone en uso. La conversión directa sólo puede tener 
éxito si la comprobación extensa se hace de antemano, y funciona mejor cuando se pueden 
tolerar algunos retrasos en el procesamiento. A veces, la conversión directa se hace en res¬ 
puesta a un mandato gubernamental. Una ventaja de la conversión directa es que los usua¬ 
rios no tienen ninguna posibilidad de usar el sistema viejo en lugar del nuevo. La adaptación 
es una necesidad. 

La conversión directa se considera como un enfoque arriesgado para la conversión y 
sus desventajas son muchas. Por ejemplo, podrían suceder grandes retrasos si ocurren 
errores, debido a que no hay ninguna forma alterna para realizar el procesamiento. Ade¬ 
más, los usuarios podrían notar que se les obliga a usar un sistema desconocido sin recurso. 
Por último, no hay ninguna forma adecuada para comparar los nuevos resultados con los 
viejos. 

Conversión paralela La conversión paralela se refiere a ejecutar al mismo tiempo el siste¬ 
ma viejo y el nuevo, en paralelo. Es el enfoque de conversión más frecuentemente usado, 
pero su popularidad podría estar bajando debido a que funciona mejor cuando un sistema 
computarizado reemplaza uno manual. Ambos sistemas se ejecutan simultáneamente por 
un periodo específico y la confiabilidad de los resultados se examina. Cuando se obtienen 
los mismos resultados todo el tiempo, el nuevo sistema se pone en uso y el viejo se detiene. 
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Una ventaja de ejecutar ambos sistemas en paralelo es la posibilidad de verificar los 
nuevos datos contra los viejos para percibir cualesquier errores en el procesamiento del nue¬ 
vo sistema. El procesamiento paralelo también ofrece un sentido de seguridad para los 
usuarios, quienes no están obligados a hacer un cambio abrupto al nuevo sistema. 

Hay muchas desventajas para la conversión paralela. Se incluyen el costo de ejecutar 
dos sistemas al mismo tiempo y el agobio en los empleados de virtualmente doblar su carga 
de trabajo durante la conversión. Otra desventaja es que a menos que el sistema a ser reem¬ 
plazado sea manual, es difícil hacer comparaciones entre las salidas del nuevo sistema y el 
viejo. Supuestamente, el nuevo sistema se creó para mejorar el viejo. Por lo tanto, las salidas 
de los sistemas deben diferir. Por último; es entendible que los empleados que se enfrentan 
con la opción de escoger de entre dos sistemas continuarán usando el viejo debido a su fa¬ 
miliaridad con él. 

Conversión gradual La conversión gradual, o por fases, intenta combinar las mejores carac¬ 
terísticas de los dos planes previamente mencionados, sin incurrir en todos los riesgos. En 
este plan, el volumen de las transacciones manejado por el nuevo sistema aumenta gradual¬ 
mente conforme el sistema se introduce por fases. Las ventajas de este enfoque incluyen 
permitir a usuarios que se involucren gradualmente con el sistema y la posibilidad de des¬ 
cubrir y recuperar errores sin desperdiciar mucho tiempo. Las desventajas de la conversión 
gradual incluyen tomar demasiado tiempo para colocar el nuevo sistema en el lugar y su im¬ 
propiedad para la conversión de sistemas pequeños y sencillos. 

Conversión de prototipo modular La conversión de prototipo modular usa la construc¬ 
ción de prototipos modulares y operacionales (como se discutió en el capítulo 6} para cam¬ 
biar de los sistemas viejos a los nuevos de forma gradual. Conforme se modifique y acepte 
cada módulo, se pone en uso. Una ventaja es que cada módulo se prueba completamente 
antes de ser usado. Otra ventaja es que los usuarios se familiarizan con cada módulo confor¬ 
me se vuelve operacional. 

Con frecuencia no es posible la elaboración de prototipos, la cual automáticamente 
cancela este enfoque para muchas conversiones. Otra desventaja es que se debe poner espe¬ 
cial atención a las interfaces para que los módulos que se construyen realmente trabajen 
como un sistema. 

Conversión distribuida La conversión distribuida se refiere a una situación en que se con¬ 
templan muchas instalaciones del mismo sistema, como es el caso en actividades bancarias 
o franquicias tal como restaurantes o tiendas de ropa. Una conversión completa se hace 
(con cualquiera de los cuatro enfoques considerado previamente) en un sitio. Cuando esta 
conversión se completa exitosamente, se hacen otras conversiones para otros sitios. 

Una ventaja de la conversión distribuida es que se pueden detectar y contener los pro¬ 
blemas en lugar de infligir simultáneamente en todos los sitios. Una desventaja es que incluso 
cuando una conversión es exitosa, cada sitio tendrá sus propias peculiaridades para trabajar 
y se deben manejar como corresponde. 

Se recomienda un enfoque de contingencia para decidir una estrategia de conversión; 
es decir, el analista considera muchos factores (incluso los deseos de los clientes) en la selec¬ 
ción de una estrategia de conversión. Obviamente, ningún enfoque de conversión particular 
es igual de conveniente para cada implementación del sistema. 


AS PÉCTDS' F E S ÉG 0 RID A D” PAR AL 0 A SIST E MAS T R A DIC10 NAL ES 
Y LOS BASADOS EN WEB 

La seguridad de las instalaciones de cómputo, almacén de datos y la información generada 
es parte de una conversión exitosa. Como se discutió en el capítulo 1, el reconocimiento de 
la necesidad de seguridad es una consecuencia natural de la creencia de que la información 
es un recurso organizacional importante. Con las transacciones complejas en aumento y 
muchos intercambios innovadores, la Web ha producido un incremento en las preocupacio¬ 
nes de seguridad para el mundo profesional de SI. 
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Es útil pensar en la seguridad de sistemas, datos e información en un continuo imagina¬ 
rio que va desde seguridad total hasta acceso abierto completamente. Aunque no hay tal co¬ 
sa como un sistema totalmente seguro, las acciones de los analistas y usuarios pretenden 
mover los sistemas hacia el lado más seguro del espectro, disminuyendo la vulnerabilidad 
del sistema. Se debe observar que conforme más personas en la organización obtienen ma¬ 
yor poder de la computadora, obtienen acceso a la Web, o se acoplan a las intranets y extra- 
nets, la seguridad se vuelve incrementalmente difícil y compleja. A veces, las organizaciones 
contratarán a un consultor de seguridad para trabajar con el analista de sistemas cuando la 
seguridad es crucial para el funcionamiento exitoso. 

La seguridad es responsabilidad de todos aquellos que están en contacto con el sistema, 
y sólo es tan buena como la conducta más indefinida o la política en la organización. La se¬ 
guridad tiene tres aspectos interrelacionados: físico, lógico y conductual. Los tres deben tra¬ 
bajar juntos si la calidad de seguridad permanece alta. 


SEGURIDAD FÍSICA 

La seguridad física se refiere a proteger el sitio donde se encuentra la computadora, su 
equipo y software a través de medios físicos. Puede incluir acceso controlado a las salas de 
cómputo por medio de signos legibles por la máquina o un registro de entrada y salida del 
sistema por un humano, usando cámaras de televisión de circuito cerrado para supervisar las 
áreas de la computadora y frecuentemente apoyando los datos y almacenando los respaldos 
en un área a prueba de fuego o a prueba de agua. 

Además, el equipo de cómputo pequeño se debe asegurar para que un usuario típico no 
pueda moverlo y se debe garantizar el suministro ininterrumpido de energía eléctrica. Las 
alarmas que notifican a las personas apropiadas en caso de fuego, inundación o intrusión no 
autorizada de una persona deben estar en todo momento en funcionamiento activo. 

El analista debe tomar las decisiones acerca de la seguridad física cuando esté planean¬ 
do las instalaciones de cómputo y la compra de equipo. Obviamente, la seguridad física 
puede ser mucho mejor si se planea con antelación a la instalación real y si las salas de 
cómputo se dotan de equipo de seguridad especial cuando se construyen en lugar de equi¬ 
parse después de que están construidas. 


SEGURIDAD LÓGICA 

La seguridad lógica se refiere a los controles lógicos en el software. Los controles lógicos son 
familiares para la mayoría de los usuarios como contraseñas o códigos de autorización de al¬ 
guna clase. Cuando se usan, permiten al usuario entrar al sistema o a una parte particular de 
una base de datos con una contraseña correcta. 

Sin embargo, las contraseñas se manejan de manera descuidada en muchas organizacio¬ 
nes. Los empleados han escuchado por casualidad gritar una contraseña en las oficinas ates¬ 
tadas, grabar las contraseñas para sus pantallas de despliegue y compartir las contraseñas 
personales con empleados autorizados que han olvidado las suyas. 

El software de encriptación especial se ha desarrollado para proteger las transacciones 
comerciales en Web y las transacciones comerciales están proliferando. Sin embargo, el 
fraude de Internet también ha aumentado bruscamente con pocas autoridades capacitadas 
en identificar a los delincuentes y se evidencia una mentalidad de "salvaje oeste" o "última 
frontera" en esos casos cuando las autoridades han podido aprehender a los delincuentes de 
Web. 

Una forma para que las redes reduzcan el riesgo de exposición al desafío de la seguri¬ 
dad del mundo exterior es construir un firewall o un sistema similar. Un firewall construye 
una muralla entre la red interna y la externa de una organización (tal como Internet). Se 
asume que la red interna es confiable y segura, mientras que Internet no lo es. Se pretende 
que los firewalls impidan comunicación dentro o fuera de la red que no haya sido autorizada 
y que no se requiera. Un sistema firewall no es un remedio perfecto para la seguridad orga- 
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nizacional y de Internet; sin embargo, es una capa adicional de seguridad que ahora se acep¬ 
ta ampliamente. Todavía no hay ninguna forma totalmente integrada de solucionar los pro¬ 
blemas de seguridad con las redes internas y externas, pero merecen la atención de analistas 
al diseñar cualquier sistema nuevo o mejorado. 

Los controles lógicos y físicos son importantes, pero no son suficientemente claros para 
proporcionar la seguridad adecuada. Los cambios conductuales también son necesarios. 


SEGURIDAD CONDUCTUAL 

Las expectativas conductuales de una organización están implícitas en sus manuales de po¬ 
lítica e incluso en letreros anunciados en los carteles de anuncios, como vimos en el capítu¬ 
lo 5. Sin embargo, la conducta que los miembros de la organización asimilan también es crí¬ 
tica para el éxito de los esfuerzos de seguridad. [Una razón por la que los firewalls no son 
totalmente a prueba de ataques es que muchos ataques a los sistemas de información vie¬ 
nen de adentro de la organización.] 

La seguridad puede empezar con la identificación de empleados que eventualmente 
tendrán acceso a las computadoras, datos e información, para asegurar que sus intereses son 
consistentes con los intereses de la organización y que entienden por completo la impor¬ 
tancia de llevar a cabo los procedimientos de seguridad. Se deben escribir, distribuir y ac¬ 
tualizar las políticas con respecto a la seguridad para que los empleados estén totalmente 
conscientes de las expectativas y responsabilidades. Es típico que el analista de sistemas 
primero tendrá contacto con los aspectos conductuales de la seguridad. Algunas organiza¬ 
ciones han escrito reglas o políticas que prohiben a los empleados navegar en Web durante 
horas de trabajo o incluso prohiben totalmente la navegación de Web, si el equipo de la 
compañía está involucrado. Otras corporaciones usan software que bloquea el acceso a los 
sitios Web que se consideran inaceptables en el lugar de trabajo, tal como juegos, apuestas 
o sitios pornográficos. 

Parte del aspecto conductual de seguridad es supervisar la conducta a intervalos irregu¬ 
lares para cerciorarse de que se están siguiendo los procedimientos apropiados y para corregir 
cualesquier conductas que se podrían deteriorar con el tiempo. Hacer que el sistema registre 
el número de inicios de sesión fallidos del usuario es una forma de supervisar si usuarios 
no autorizados están intentando iniciar sesión del sistema. Es conveniente inventariar pe¬ 
riódica y frecuentemente el equipo y software. Además, se deben examinar sesiones largas 
inusuales o el acceso al sistema atípico después de las horas de oficina. 

Los empleados deben entender claramente lo que se espera de ellos, lo que se prohibe 
y la magnitud de sus derechos y responsabilidades. Debe comunicar al personal acerca de 
toda la supervisión que se está haciendo o que se está contemplando y debe proporcionar la 
razón para esto. Dicha comunicación debe incluir el uso de cámaras de vídeo y software de 
supervisión. 

La salida generada por el sistema se debe reconocer por su potencial de poner a la or¬ 
ganización en riesgo en algunas circunstancias. Los controles para la salida incluyen panta¬ 
llas que sólo se pueden acceder mediante la contraseña, la clasificación de información (es 
decir, a quién se puede distribuir y cuándo) y el almacenamiento seguro de documentos im¬ 
presos y almacenados magnéticamente. 

En algunos casos, se deben tomar medidas para destruir documentos confidenciales. 
Los servicios de destrucción o pulverización se pueden contratar con una empresa externa 
que, por una cuota, destruirá medios magnéticos, cartuchos de impresora y papel. Una cor¬ 
poración grande puede destruir anualmente más de 17,000 kilos de material de salida en 
una variedad de medios. 


CONSIDERACIONES ESPECÍALES DE SEGURIDAD PARA EL COMERCIO ELECTRÓNICO 

Se sabe bien que los intrusos pueden violar la integridad de cualquier sistema de cómpu¬ 
to. Como analista, necesita tomar diversas precauciones para proteger la red de cómputo de 
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las amenazas de seguridad en Web internas y externas. Varias acciones y productos le pue¬ 
den ayudar: 

1. Software antivirus. 

2. Productos de filtración de correo electrónico (como el Mail-Gear de Symantec) 
que proporciona servicios de filtrado de correo electrónico y archivos adjuntos basado 
en políticas y revisión para proteger a las compañías del correo electrónico entrante y 
saliente. La revisión del correo entrante protege contra ataques spam (correo electrónico 
no solicitado como los anuncios publicitarios) y la revisión del correo saliente protege 
contra la pérdida de información propia. 

3. Productos de filtración de URL que proporcionan a los empleados acceso a Web por 
usuario, por grupos de usuarios, por computadoras, por tiempo o por el día de la semana. 

4. Firewalls, gateways y redes privadas virtuales que impiden a los hackers acceder de for¬ 
ma clandestina a una red corporativa. 

5. Productos de detección de intrusión (tal como Intruder Alert de Symantec) que conti¬ 
nuamente supervisan el uso, proporcionan mensajes e informes y sugieren acciones a 
tomar. 

6. Productos de administración de vulnerabilidad (tal como NetRecon y Symantec Ex- 
pert) que evalúa los riesgos potenciales en un sistema y descubre e informa las vulnera¬ 
bilidades. Algunos productos correlacionan las vulnerabilidades para que sea más fácil 
encontrar la raíz de los problemas. El riesgo no se puede eliminar, pero este software 
puede ayudar a manejarlo al equilibrar el riesgo de seguridad contra los costos de eli¬ 
minarlos. 

7. Tecnologías de seguridad tal como la capa de conexiones seguras (SSL) para la autenti¬ 
cación. 

8. Tecnologías de encriptación tal como interpretación electrónica segura (SET). 

9. Infraestructura de clave pública (PKI) y certificados digitales (obtenidos de una compa¬ 
ñía tal como Verisign). El uso de certificados digitales asegura que el remitente infor¬ 
mado del mensaje realmente es la compañía que envió el mensaje. 


CONSIDERACIONES DE PRIVACIDAD PARA EL COMERCIO ELECTRÓNICO 

El otro lado de la seguridad es la privacidad. Para hacer su sitio Web más seguro, debe pedir 
a los usuarios o clientes que renuncien a alguna privacidad. 

Como diseñador de un sitio Web, reconocerá que se ejerce mucho poder sobre los da¬ 
tos de los clientes de la compañía para la cual diseña. Los mismos principios de conducta 
ética y legal se aplican al diseño del sitio Web como al diseño de cualquier aplicación tradi¬ 
cional que acepta datos personales de clientes. Sin embargo. Web permite recopilar datos 
más rápidamente y diferentes (tal como los hábitos de navegar del cliente). En general, la 
tecnología de información hace posible almacenar más datos en los almacenes de datos, 
procesarlos y distribuirlos más ampliamente. 

Cada compañía para la cual diseña una aplicación de comercio electrónico debe adop¬ 
tar una política de privacidad. Aquí hay algunos lincamientos: 


1. Inicie con una política corporativa de privacidad. Asegúrese que se despliega de forma 
prominente en el sitio Web para que todos los clientes puedan acceder la política siem¬ 
pre que completen una transacción. 

2. Sólo pida la información que requiere la aplicación para completar la transacción en 
cuestión. Por ejemplo, ¿es necesario para la transacción preguntar la edad o género de 
una persona? 

3. Haga opcional para los clientes completar la información personal en el sitio Web. A al¬ 
gunos clientes no les importa recibir mensajes concretos, pero siempre debe dar una 
oportunidad a los clientes de mantener la confidencialidad de sus datos personales al 
no responder. 

4. Use fuentes que le permitan obtener información anónima sobre las clases de clientes. 
Por ejemplo, Engage es una compañía que ofrece al público tecnología de perfiles y so- 
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luciones de tecnología para administrar los anuncios, sus objetivos y su entrega. Esto se 
hace para mantener una base de datos dinámica de perfiles del cliente sin vincularlos a 
los individuos, por ello se respetan los derechos de privacidad de los clientes. 

5. Sea ético. Evite el uso de trucos baratos que permitan a su cliente recopilar la informa¬ 
ción sobre el cliente de formas sospechosas o poco éticas. Los trucos tales como el ras¬ 
pado de pantalla (capturar remotamente lo que está en la pantalla de un cuente] y la 
toma de cookies de correo electrónico son violaciones claras de privacidad y también 
podrían ser ilegales. 

Es esencial una política coordinada de seguridad y de privacidad. Es esencial establecer 
estas políticas y adherirse a ellas al implementar una aplicación de comercio electrónico. 


C0NSI D E RAC10N ES DE 

La conversión también trae consigo otros detalles para el analista, los cuales incluyen lo si¬ 
guiente: 

1. Pedir equipo (hasta tres meses antes de la conversión planeada). 

2. Pedir cualesquier materiales necesarios que se proporcionan externamente al sistema 
de información, tal como cartuchos de tinta, papel, formularios impresos previamente 
y los medios magnéticos. 

3. Designar un gerente para supervisar, o supervisar personalmente, la preparación del si¬ 
tio de la instalación. 

4. Planear, fijar y supervisar a programadores y personal de captura de datos que deben 
convertir todos los archivos y bases de datos relevantes. 

Para muchas implementaciones, su papel principal será estimar con precisión el tiempo ne¬ 
cesario para cada actividad, nombrar a las personas para manejar cada subproyecto y coor¬ 
dinar su trabajo. Para proyectos más pequeños, hará mucho del trabajo de conversión por 
usted mismo. Muchas de las técnicas de administración de proyecto discutidas en el capítu¬ 
lo 3, tal como las gráficas de Gantt, PERT y comunicación exitosa con los miembros del 
equipo, son útiles para diseñar y controlar la implementación. 



CONVERSIÓN 


METÁFORAS ORGANIZACIONALES Y SU RELACIÓN CON LOS SISTEMAS EXITOSOS 

Esté consciente de las metáforas organizacionales cuando intente implementar un sistema 
que ha desarrollado recientemente. Nuestra investigación ha sugerido que el éxito o fracaso 
de un sistema podrían tener algo que hacer con las metáforas usadas por los miembros de la 
organización. 

Cuando las personas en la organización describen la compañía como un zoológico, 
puede inferir que la atmósfera es caótica; si se describe como una máquina, todo está fun¬ 
cionando en un estilo ordenado. Cuando la metáfora predominante es guerra, expedición o 
selva, el ambiente es caótico, como con el zoológico. Sin embargo, las metáforas guerra y ex¬ 
pedición se orientan hacia una meta de la organización, mientras que las metáforas zoológi¬ 
co y selva no. 

Además de máquina, las metáforas tal como sociedad, familia y juego significan orden 
y reglas. Aunque las metáforas máquina y juego se orientan a un objetivo, las metáforas so¬ 
ciedad y zoológico no enfatizan el objetivo de la compañía, sino que permiten a los indivi¬ 
duos en la corporación establecer sus propios estándares y premios. Otra metáfora, organis¬ 
mo, parece equilibrada entre orden y caos, objetivos corporativos e individuales. 

Nuestra investigación sugiere que el éxito o fracaso de un sistema podrían tener algo 
que ver con la metáfora predominante. La figura 17.12 muestra que un sistema de informa¬ 
ción gerencial tradicional tenderá a tener éxito cuando la metáfora predominante es socie¬ 
dad, máquina o familia, pero no podría tener éxito si la metáfora es guerra o selva (dos me- 
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táforas caóticas). Sin embargo, observe que los sistemas competitivos probablemente ten¬ 
drán éxito si la metáfora es guerra. 

Las metáforas positivas parecen ser juego, organismo y máquina. Las metáforas negati¬ 
vas parecen ser selva y zoológico. Las otras (expedición, guerra, sociedad y familia) mues¬ 
tran éxito mezclado dependiendo del tipo de sistema de información que se desarrolla. Se 
necesita hacer más investigación en esta área. Mientras tanto, el analista de sistemas debe es¬ 
tar consciente de que las metáforas comunicadas en las entrevistas podrían ser significativas 
e incluso podrían ser un factor de contribución hacia el éxito de la implementación del sis¬ 
tema de información. 


EVALUACIÓN 

A lo largo del ciclo de vida del desarrollo de sistemas, el analista, los directivos y los usuarios 
han estado evaluando la evolución de los sistemas de información y las redes para propor¬ 
cionar retroalimentación para su mejora eventual. La evaluación también se necesita para 
dar seguimiento a la implementación del sistema. 


TÉCNICAS DE EVALUACIÓN 

En reconocimiento de que la evaluación continua de sistemas de información y redes es im¬ 
portante, se han inventado muchas técnicas de evaluación. Estas técnicas incluyen análisis 
costo-beneficio (como se discutió en el capítulo 10); modelos que intentan estimar el valor 
de una decisión con base en los efectos de la información y que usan teoría de informa¬ 
ción, simulación o estadísticas bayesianas; evaluaciones del usuario que enfatizan los pro¬ 
blemas de implementación y participación del usuario, y enfoques de utilidad de sistemas 
de información que examinan las propiedades de la información. 

Cada tipo de evaluación sirve para un propósito diferente y tiene desventajas inheren¬ 
tes. El análisis costo-beneficio podría ser difícil de aplicar, debido a que los sistemas de in¬ 
formación proporcionan información acerca de los objetivos para la primera vez, haciendo 
imposible comparar el desempeño antes y después de la implementación del sistema o red 
distribuida. El enfoque de evaluación de decisión revisada presenta dificultad, debido a que 
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todas las variables involucradas con el diseño, desarrollo e implementación del sistema de 
información no se pueden calcular o cuantificar. El enfoque de participación del usuario 
produce algún entendimiento para los nuevos proyectos al proporcionar una lista de control 
de la conducta potencialmente disfuncional por varios miembros organizacionales, pero en¬ 
fatiza la implementación sobre otros aspectos del diseño del SI. El enfoque de utilidad de 
sistemas de información para la evaluación puede ser más completo que otros si se extien¬ 
de y se aplica sistemáticamente. 


ENFOQUE DE UTILIDAD DEL SISTEMA DE INFORMACIÓN 

El enfoque de utilidad del sistema de información para evaluar los sistemas de información 
puede ser una técnica completa y fructífera para medir el éxito de un sistema desarrollado. 
También puede servir como una guía en el desarrollo de cualesquier proyectos futuros que 
el analista podría emprender. 

Las utilidades de información incluyen posesión, forma, lugar y tiempo. Para evaluar el 
sistema de información integralmente, estas utilidades se deben extender para incluir utili¬ 
dad de actualización y utilidad del objetivo. Después las utilidades se pueden ver para res¬ 
ponder adecuadamente las preguntas de quién (posesión], qué (forma), dónde (lugar), cuán¬ 
do (tiempo), cómo (actualización) y por qué (objetivo). En la evaluación de un sistema de 
inventario de sangre de la figura 17.13 se puede ver un ejemplo de este enfoque de utilidad 
de información. 

Utilidad de posesión La utilidad de posesión responde la pregunta de quién debe recibir 
la salida o, dicho de otro modo, quién debe ser responsable de tomar las decisiones. La infor- 
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OPORTUNIDAD 


CONSULTARÍA 


LIMPIANDO EL NUEVO SISTEMA 


"No sé ¡o que pasó. Cuando se instaló ei nuevo sistema, los analistas 
salieron limpiamente, hasta donde puedo recordar", dice Maro Schmeder, 
en tono filosófico. Como vimos,, él es dueño de Maro Schnieder Jánitoriai 
Supply Company. (Usted vio a Maro por ultima vez en la Oportunidad de 
consultorfa 13.1, cuando le ayudó a solucionar sus necesidades de al¬ 
macenamiento de datos. En ese lapso, en la empresa de Marc instalaron 
un nuevo sistema de ¡nfórmaóióri:)'.*;X: ; K 

"El equipo de análisis de sistemas nos hizo algunas preguntas sobre 
qué nos había parecido el nuevo sistema", Marc agrega con impacien¬ 
cia. "Nunca supimos, cómo decirles que la salida no. era tan limpia como 
hubiéramos querido. Es decir, era confusa. Por ejemplo; no le llegaba a la 


gente adecuada en el momento oportuno. En realidad nunca pudimos 
discutir de los pequeños detalles del sistema terminado con ese equipo 
de consultores. Siento como si hubiéramos tenido que contratar a su 
grupo simplemente para que limpiaran lo que ellos ensuciaron." 

Después de posteriores conversaciones con Stan Lessink, el jefe de 
programadores de la compañía, usted llega a la conclusión de que el 
equipo que hizo la instalación inicial no tenía ningún mecanismo de eva¬ 
luación. Sugiera un marco de trabajo adecuado para evaluar las inquietu- 
des que le surgieron al señor Schnieder sobre el sistema. ¿Qué problemas 
pueden ocurrir cuando un sistema no se evalúa de manera sistemática? 
Explique su respuesta en un párrafo. 


dulo completo estará destinado a fallar. Un logro parcial o "justo" de una utilidad producirá 
un módulo parcialmente exitoso. Si el módulo del sistema de información se juzga como 
"bueno" proporcionando cada utilidad, el módulo es un éxito. 

El enfoque de utilidad del sistema de información de "quién, qué, cuándo, cómo, dónde 
y por qué" usado para evaluar el sistema de información de administración de inventario 
de sangre regional resulta de los juicios subjetivos acerca de la utilidad del sistema de infor¬ 
mación resumidos en la figura 17.13. Como puede ver, tres de los módulos se calificaron 
como "buenos" en cada categoría de utilidad y por consiguiente estos módulos se considera¬ 
ron exitosos. Un módulo se juzga como fracaso después del periodo de pruebas. También se 
proporcionan las explicaciones de cada juicio hechas en los cuatro módulos. 

El enfoque de utilidad del sistema de información es un marco de trabajo utilizable y 
sencillo para evaluar proyectos extensos de sistemas de información y los esfuerzos en pro¬ 
ceso. También se puede emplear como una lista de control para supervisar el progreso de 
sistemas en desarrollo. Además, la evaluación que sigue la implementación permite al ana¬ 
lista adquirir ideas sobre cómo proceder con los proyectos de sistemas futuros. 


EVALUACION DE SITIOS WEB CORPORATIVOS 

La evaluación del sitio Web corporativo que está desarrollando o manteniendo es una parte 
importante de cualquier esfuerzo de implementación exitoso. Los analistas pueden usar el 
enfoque de utilidad del sistema de información previamente descrito para evaluar las cali¬ 
dades estéticas, contenido y entrega del sitio. Como analista o administrador Web, debe ir 
un paso más adelante y analizar el tráfico Web. 

Un visitante a su sitio Web puede generar gran cantidad de información útil para que 
usted la analice. Esta información se puede recopilar automáticamente al capturar informa¬ 
ción sobre la fuente, incluyendo el último sitio Web que el usuario visitó y las palabras cla¬ 
ve usadas para encontrar el sitio; la información también se puede obtener mediante el uso 
de cookies (archivos colocados en la computadora de un visitante acerca de cuándo visitó 
por última vez el sitio). 

Uno de los paquetes principal para monitorear actividad de Web Webtrends. La figu¬ 
ra 17.14 es una muestra de un reporte que lista los archivos más transmitidos en el sitio 
Web por día de la semana. El gráfico despliega los primeros cinco archivos transmitidos y la 
tabla inferior es una lista ordenada de todas las descargas. 

Un analista o administrador Web pueden obtener información valiosa usando un servi¬ 
cio tal como Webtrends. (Aunque algunos servicios son gratuitos, los servicios de pago nor- 
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Muestra de un reporte de 
Webtrends Corporation que 
muestra los archivos que más 
se descargaron en el sitio Web 
corporativo. 
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malmente proporcionan el detalle necesario para evaluar a fondo el sitio. El costo se consi¬ 
dera un costo de operación para mantener el sitio Web.) La información para ayudarle a 
evaluar el sitio de su cliente y hacer mejoras es abundante y fácil de obtener. Los siete ar¬ 
tículos esenciales se describen a continuación. 


■■ , - - mm:j ] 


1. Sepa con qué frecuencia se visita el sitio Web de su cliente. Algunas de las cosas que 
necesita saber son el número de consultas que tuvo un sitio Web en los últimos días, el 
número de sesiones de visitantes y el número de páginas visitadas. Para evaluar apropia¬ 
damente un sitio, debe conseguir información más detallada acerca del tráfico que está 
recibiendo el sitio del cliente. 

2. Aprenda detalles acerca de páginas específicas en el sitio. La información detallada 
sobre las páginas accesadas ayuda a evaluar el contenido y la habilidad de navegar el 
sitio. Con frecuencia una clave importante es cuando la última página visitada es una 
página que contiene los precios de sus productos. Además, puede seguir las estadísticas 
de las páginas más solicitadas, los temas más solicitados, las rutas superiores que un 
visitante sigue a través del sitio Web del cliente o incluso los archivos más transmitidos. 
Si el sitio Web es comercial, los informes del carrito de compras pueden mostrar cuán¬ 
tos visitantes se convirtieron en compradores y cuántos abandonaron sus carritos o no 
completaron el proceso de pago. 

3. Averigüe más sobre los visitantes del sitio Web. La demografía e información del vi¬ 
sitante tal como el número de visitas por un visitante particular en un periodo, si el 
visitante es nuevo o uno que está regresando, y quiénes son los visitantes más fre¬ 
cuentes es información valiosa al evaluar un sitio Web. Es posible conseguir datos de 
resumen sobre la región geográfica o incluso la ciudad más representada por los visi¬ 
tantes al sitio. 

La figura 17.15 muestra una página que compara las estadísticas seleccionadas de 
los visitantes en un lapso de tiempo. El gráfico superior muestra a los visitantes, el grá¬ 
fico intermedio muestra a los visitantes que realizan su primera visita y el gráfico infe¬ 
rior despliega la duración media de visitas. Esta información permite al analista evaluar 
el sitio Web en lo que se refiere a la habilidad de atraer nuevos visitantes y mantenerlos 
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una vez que han visitado el sitio. Observe que el calendario de la esquina superior iz¬ 
quierda se puede usar para cambiar la vista de diario a semana o de mes. Este servicio 
lo provee el paquete Commerce Trends, de Webtrends Corporation. 

4. Descubra si los visitantes pueden completar adecuadamente los formularios que dise¬ 
ñó. Una vez que atrae y mantiene a los visitantes, necesita saber si están completando 
adecuadamente los formularios y si entienden el sitio del cliente en general. Si el por¬ 
centaje de error es alto, rediseñe el formulario y vea lo que sucede. El análisis de las es¬ 
tadísticas revelará si un mal diseño de formulario puede ser culpable por los errores en 
las respuestas. 

5. Averigüe quién envía a los visitantes al sitio del cliente. Averigüe cuáles sitios son res¬ 
ponsables de enviar a los visitantes al sitio Web del cliente. Consiga estadísticas de los 
sitios que le han enviado más tráfico, los motores de búsqueda más efectivos e incluso 
las palabras clave que los visitantes usaron para localizar el sitio Web de su cliente. 

Para aumentar la presencia Web de su compañía, la promoción del sitio es crítica. 
Hay muchos servicios disponibles, como NetAnnounce Premier y NetMechanic, que 
ayudan a optimizar su página de inicio y crean e instalan automáticamente las metaeti- 
quetas [código HTML que usan los motores de búsqueda para clasificar un sitio Web). 
Estos servicios después envían el sitio a los motores de búsqueda líderes como Yahool, 
AltaVista, Excite, Google y HotBot. 

Después de promover un sitio, puede usar el análisis de tráfico Web para rastrear si 
la promoción del sitio realmente representó una diferencia. Debido a que la mayoría de 
usuarios que buscan un sitio Web no buscan más allá de la primera página de resultados 
de un motor de búsqueda, la promoción del sitio Web de su cliente es esencial. 

6. Determine qué navegadores están usando los visitantes. Sabiendo qué navegadores se 
están usando, puede agregar características de un navegador específico que mejoran la 
apariencia y funcionamiento del sitio y animan a los visitantes a quedarse más tiempo, 
mejorando la lealtad del sitio. Esto ayuda a saber si los visitantes están usando navega¬ 
dores actuales o anticuados. 

7. Averigüe si los visitantes del sitio Web del cliente están interesados en la publicidad. 
Por último, averigüe si los visitantes del sitio están interesados en las campañas publici- 
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tarias que tiene en su sitio. Consiga informes del éxito de anuncios publicitarios, cam¬ 
pañas de correo electrónico e incluso las campañas de correo tradicional. Puede sacar 
ventaja de los programas de afiliación y enviar a sus visitantes a otros sitios obteniendo 
una ganancia. También puede evaluar las campañas publicitarias internas, tal como 
ofrecer un descuento especial a productos por un periodo específico. 

Los servicios de monitoreo de actividad Web pueden ser útiles al evaluar si el sitio está 
cumpliendo con sus objetivos en lo que se refiere al tráfico, a la efectividad de la publicidad, 
la productividad del empleado y retorno de inversión. Ésta es una de las maneras en que un 
analista puede evaluar si la presencia Web corporativa está cumpliendo con las metas fijadas 
por la dirección y si se cumple con precisión con la visión de la organización. 



RESUMEN 

La implementación es el proceso de asegurar que los sistemas de información y las redes 
sean funcionales y después involucrar a los usuarios bien capacitados en su operación. En 
los proyectos grandes de sistemas, el papel principal del analista es vigilar la implementa¬ 
ción, estimando correctamente el tiempo necesario, y después supervisar la instalación del 
equipo para los sistemas de información (qué se podría establecer con un enfoque clien¬ 
te/servidor en una red de área local], capacitar usuarios y convertir archivos y bases de da¬ 
tos al nuevo sistema. 

Los sistemas distribuidos aprovechan la tecnología de las telecomunicaciones y de ad¬ 
ministración de bases de datos para interconectar a las personas que manipulan algunos de 
los mismos datos de formas significativas pero diferentes. Conforme se evalúan el hardware 
y software, el analista de sistemas también necesita considerar los costos y beneficios de em¬ 
plear un sistema distribuido para satisfacer los requerimientos del usuario. 

Una de las formas más populares de acercarse a los sistemas distribuidos es mediante el 
uso de un modelo cliente/servidor (C/S). Los tipos estándar de redes organizacionales in¬ 
cluyen la red de área local [LAN] y la red de área amplia [WANQ. Usando un enfoque des¬ 
cendente, los analistas pueden usar cinco símbolos para ayudar a dibujar la descomposición 
de la red y diagramas de conectividad de hub. El software especializado, denominado 
groupware, se escribe específicamente para apoyar a grupos o equipos de trabajadores con 
aplicaciones funcionales. Su propósito es ayudar a los miembros de un grupo a trabajar en 
conjunto a través de redes. 

La capacitación de usuarios y personal para interactuar con el sistema de información 
es una parte importante de la implementación, debido a que los usuarios generalmente de¬ 
ben poder ejecutar el sistema sin la intervención del analista. El analista necesita considerar 
quiénes necesitan ser capacitados, quién los capacitará, los objetivos de la capacitación, los 
métodos de instrucción que se usan, los sitios de la capacitación y los materiales de la capa¬ 
citación. 

La conversión también es parte del proceso de implementación. El analista tiene varias 
estrategias para cambiar del sistema de información viejo al nuevo. Las cinco estrategias 
de conversión son: conversión directa, conversión paralela, conversión por fases o gradual, 
conversión de prototipo modular y conversión distribuida. Tomando un enfoque de contin¬ 
gencia para las estrategias de conversión puede ayudar al analista a escoger una estrategia 
apropiada, una que satisface diferentes variables del sistema y organizacionales. 

La seguridad de datos y sistemas ha cobrado mayor importancia para los analistas que 
diseñan más aplicaciones de comercio electrónico. La seguridad tiene varias facetas —física, 
lógica y conductual— que deben trabajar en conjunto. Los analistas pueden tomar varias 
precauciones, tal como software antivirus, filtración de correo electrónico, filtros URL, fire- 
walls, gateways, redes privadas virtuales, productos de detección de intrusión, capa de co¬ 
nexiones seguras, interpretación electrónica segura y el uso de una infraestructura de clave 
pública para mejorar la privacidad, confidencialidad y la seguridad de sistemas, redes, datos, 
individuos y organizaciones. 
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EXPERIENCIA CON HYPERGASE® 


"Como sabe, Snowden está decidido aimplementar algún tipo de seguimiento automatiza¬ 
do para la gente de Capacitación. No obstante, a pesar de que usted y su equipo han estado 
aquí en MRE todo este tiempo, a mí no me queda claro cómo se logrará eso. Incluso después 
de tenerlos a usted y a su equipo aquí a MRE durante todo este tiempo. Tal vez usted se ha¬ 
ya percatado que algunas personas como Tom Ketcham se aferran a sus formas de pensar, 
pero Snowden también es así, y él tiene la sartén por el mango. Lo que le estoy diciendo no 
es nuevo para usted, ¿verdad? Creo que para cuando Snowden regrese de Polonia, usted 
debe estar preparado para mostrarle cómo podemos implémentar un sistema dé seguimiento 
automatizado para el grupo de Capacitación, pero tiene que ser un sistema convincente 
parados nuevos usuarios. Después de todo, ellos son los que tienen que utilizarlo. Le reser¬ 
varé una reunión con Snowden para dentro de dos semanas." 

PREGUNTAS DE HYPERCASE 

1. Desarrolle un plan de implementación que pudiera servir al grüpo dé Capacitación para 
cambiar a un sistema automatizado de seguimiento de proyectos. Explique su enfoque en 
un párrafo. Asegúrese de que su plan también cumpla las expectativas de Snowden. 

2. En dos párrafos, explique qué enfoque de conversión es apropiado para adoptar un nue¬ 
vo sistema automatizado de seguimiento de proyectos para el grupo de Capacitación. 

3. Describa los pasos que tomaría para capacitar a los usuarios del grüpo de Capacitación 
con el fin de que puedan utilizar su nuevo sistema. En un párrafo, expliquemos obstácu¬ 
los que ve para capacitar a los usuarios del grupo de Capacitación. \ mencione cómo 
podría superar éstos problemas 




Las investigaciones sugieren que los analistas de sistemas pueden incrementar las posi¬ 
bilidades de que los sistemas recientemente implementados sean aceptados si desarrollan 
sistemas con metáforas predominantemente organizacionales en mente. Las nueve metáfo¬ 
ras principales en uso son sociedad, familia, máquina, organismo, expedición, juego, guerra, 
selva y zoológico. Por ejemplo, es más probable que los sistemas de información tradiciona¬ 
les tengan éxito cuando se usan metáforas tal como familia, sociedad o máquina y es menos 
probable que tengan éxito con metáforas organizacionales tal como guerra y selva. 

Después de la implementación, el nuevo sistema de información y el enfoque tomados 
(quizás la tecnología cliente/servidor) se deben evaluar. Muchos enfoques de evaluación di¬ 
ferentes están disponibles, incluyendo el análisis costo-beneficio, el enfoque de evaluación 
de decisión revisada y evaluaciones de la participación del usuario. 

El marco de referencia de la utilidad del sistema de información es una forma directa 
de evaluar un sistema nuevo basada en las seis utilidades de posesión, forma, lugar, tiempo, 
actualización y objetivo. Estas utilidades corresponden a, y responden las preguntas de, 
quién, qué, dónde, cuándo, cómo y por qué, para evaluar las utilidades del sistema de infor¬ 
mación. Las utilidades también pueden servir como una lista de control para los sistemas en 
desarrollo. 


PALABRAS Y FRASES CLAVE 


análisis del tráfico en Web 
Bluetooth 

capa de conexiones seguras (SSL) 
conectividad de hub 
configuración de bus 


consultas 

conversión de prototipo modular 
conversión directa 
conversión distribuida 
conversión gradual o por fases 
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conversión paralela 
descomposición de red 
enfoque para la evaluación 
firewall o sistema firewall 
gateway 
groupware 

infraestructura de clave pública (PKI) 
interpretación electrónica segura (SET) 
metáforas organizacionales 
expedición 
familia 
guerra 
juego 
máquina 
organismo 
selva 
sociedad 
zoológico 
modelado de red 
modelo cliente/servidor 
monitoreo de la actividad en Web 
perfiles del público 
política de privacidad corporativa 
privacidad equivalente al cableado (WEP) 
procesamiento distribuido 
productos de filtrado de correo 
electrónico 


productos de filtrado de URL 
promoción de sitio Web 
red de anillo 

red de área amplia (WAN) 
red de área local (LAN) 
red de área local inalámbrica (WLAN) 
red de estrella 
red jerárquica 
seguridad conductual 
seguridad física 
seguridad lógica 
servidor de archivos 
servidor de impresión 
sitio de envío 
software antivirus 
software de encriptación 
utilidad del sistema de información 
visitantes diferentes 

utilidad de actualización 
utilidad de formulario 
utilidad de lugar 
utilidad de objetivo 
utilidad de posesión 
utilidad de tiempo 
vista de la página 
Wi-Fi 


PREGUNTAS DE REPASO 

1. Mencione los cuatro enfoques para la implementación. 

2. Describa lo que significa sistema distribuido. 

3. Mencione todos los términos proporcionados en el texto para describir una red de área 
local inalámbrica. 

4. Mencione dos razones por las que una organización pueda preferir establecer una 
WLAN en lugar de una LAN. 

5. ¿Cuáles son dos desventajas para la implementación de una red Wi-Fi? 

6. ¿Qué significa WEP? 

7. ¿Por qué se recomienda WEP para usarse en las redes Wi-Fi? 

8. ¿Qué es una red jerárquica? 

9. Construya una red de estrella y etiquete los nodos apropiadamente. 

10. ¿Cómo difiere una red de anillo de una red de estrella? 

11. ¿Qué es una configuración de bus para el procesamiento distribuido? 

12. ¿Qué es el modelo cliente/servidor? 

13. Describa cómo es diferente un cliente de un usuario. 

14. ¿Qué es una red de igual a igual? ¿Cómo difiere de otras redes cliente/servidor? 

15. ¿Qué es un servidor de archivos? 

16. ¿Cuáles son las ventajas de usar un enfoque cliente/servidor? 

17. ¿Cuáles son las desventajas de usar un enfoque cliente/servidor? 

18. ¿Cuál es el propósito de groupware? 

19. ¿Quién se debe capacitar para usar el sistema de información nuevo o modificado? 

20. Mencione las cinco fuentes posibles de capacitación para usuarios de sistemas de in¬ 
formación. 

21. ¿Por qué es importante tener objetivos de capacitación bien definidos? 
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22. Algunos usuarios aprenden mejor viendo, otros oyendo, e incluso otros haciendo. Dé un 
ejemplo de cómo cada tipo de aprendizaje se puede incorporar en una sesión de capa¬ 
citación. 

23. Declare una ventaja y una desventaja de las sesiones de capacitación en el sitio. 

24. Mencione los atributos de los materiales de capacitación bien ejecutados para los usuarios. 

25. Mencione las cinco estrategias de conversión para convertirlos sistemas de información 
viejos a nuevos. 

26. Defina los términos seguridad física, lógica y conductual y dé un ejemplo de cada uno 
que ilustre las diferencias entre ellos. 

27. Defina qué significa software de encriptación. 

28. ¿Qué es un ñrewall o sistema ñrewall? 

29. Mencione cinco de las medidas que un analista puede tomar para mejorar la seguridad, 
privacidad y confidencialidad de datos, sistemas, redes, individuos y organizaciones que 
usan aplicaciones Web de comercio electrónico. 

30. Mencione cinco lincamientos para diseñar una política de privacidad corporativa para 
las aplicaciones de comercio electrónico. 

31. Mencione las nueve metáforas organizacionales y el éxito hipotético de cada tipo de 
sistema dada su presencia. 

32. Mencione y describa las utilidades de sistemas de información que se pueden usar para 
evaluar el sistema de información. 

33. ¿Cuáles son los siete artículos esenciales que el analista debe incluir en el desempeño 
del análisis de tráfico de un sitio Web? 


PROBLEMAS 


1. Dibuje una red de área local, o alguna otra configuración de procesamiento distribuido 
que use el enfoque cliente/servidor, para resolver algunos de los problemas con la com¬ 
partición de datos que está teniendo la compañía de construcción Bakerloo Brothers. 
La empresa quiere que equipos de arquitectos trabajen en diseños en la oficina princi¬ 
pal, permitir al supervisor de la construcción introducir los cambios de último momento 
a los planos de obras en proceso y permitir a clientes ver los diseños casi en cualquier 
parte. Actualmente, la compañía tiene una LAN para los arquitectos que están en una 
ciudad [Filadelfia] que les permite compartir algunas herramientas de dibujo y cual¬ 
quier actualización que los miembros del equipo hacen con los arquitectos en otras 
ciudades (Nueva York, Terre Haute, Milwaukee, Lincoln y Vancouver). El supervisor 
usa una computadora portátil, no puede hacer ningún cambio y no se conecta a una ba¬ 
se de datos. Los clientes ven los diseños en las pantallas, pero los representantes de ven¬ 
tas no pueden introducir las modificaciones para mostrarles lo que pasaría si una pared 
se moviera o si se alterara una línea del tejado. [Sugerencia: mencione los problemas 
que la compañía está encontrando, analice los síntomas, piense en una solución y des¬ 
pués empiece a dibujar.) Se podría necesitar más de una red y no todos los problemas 
se prestan a una solución de sistemas. 

2. Cramtrack, el sistema de tren regional, está intentando capacitar a los usuarios de su 
sistema de cómputo recientemente instalado. Para conseguir la capacitación adecuada 
de usuarios, los analistas de sistemas involucrados con el proyecto enviaron un memo¬ 
rándum a los jefes de los cuatro departamentos que incluye a usuarios principales y se¬ 
cundarios. El memorándum decía en parte, "Sólo las personas que sienten que requie¬ 
ren capacitación necesitan hacer las reservaciones para la capacitación externa; todos 
los demás deben aprender el sistema conforme trabajen con él". Sólo se inscribieron 
tres usuarios de 42 posibles. Los analistas están satisfechos de que el memorándum 
protegió eficazmente a las personas que necesitan la capacitación de aquellos que no 
la necesitan. 

a. En un párrafo, explique qué puede estar mal en el enfoque que los analistas siguie¬ 
ron para capacitar. 
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b. Delinee los pasos que seguiría para asegurar que las personas correctas de Cram- 
track están capacitadas. 

c. En un párrafo sugiera cómo se debería usar Web para ayudar en la capacitación 
para Cramtrack. 

3. Un folleto bonito y lleno de color llegó al escritorio de Bill Cornwell que describe el 
programa de capacitación externa y las instalaciones de la Benny Company en términos 
muy favorables; mostró a los usuarios felices y a instructores profesionales que se apoyan 
en ellos con aspecto interesado. Bill se dirigió agitadamente hacia la oficina de Roseann 
y le dijo: "Tenemos que usar a estas personas. [Este lugar se ve excelente!" Roseann no 
se convenció por el folleto, pero no supo qué decir en defensa de la capacitación inter¬ 
na para usuarios que ella ya había autorizado. 

a. En unas frases, ayude a Roseann a argumentar la utilidad la capacitación interna 
con instructores internos en comparación con la capacitación externa con instruc¬ 
tores contratados externamente. 

b. Si Bill se decide por la capacitación de la Benny Company, ¿qué debe hacer para 
verificar que esta compañía es de hecho el lugar correcto para capacitar a los usua¬ 
rios del sistema de información de la compañía? Haga una lista de acciones que de¬ 
ba seguir. 

4. "Sólo un poco más grande... Quiero estar seguro que está trabajando correctamente 
antes de que cambie de opinión", dice Bufiy, la dueña de tres boutiques de accesorios 
de baño denominado Tub'n Stuff. Su contador, quien le ayudó a establecer un nuevo 
sistema de información de contabilidad, está intentando desesperadamente persuadir a 
Bufiy de migrar completamente hacia el nuevo sistema. Bufiy ha insistido en ejecutar 
los sistemas viejos y nuevos en paralelo durante un año entero. 

a. Describa brevemente los problemas generales involucrados al usar una estrategia 
de conversión paralela para implementar un nuevo sistema de información. 

b. En un párrafo, intente convencer al dueño de Tub'n Staff de que un año para eje¬ 
cutar un sistema en paralelo es mucho tiempo. Sugiera una forma de acabar los sis¬ 
temas duales de Tub'n Staff que proporcione bastante certeza a Bufiy. (Asuma que 
el nuevo sistema es confiable.) 

5. Delinee un diseño para desempeñar el análisis de tráfico Web para la aplicación del co¬ 
mercio electrónico desarrollada para Marathón Vitamin Shops. (Véanse las Oportuni¬ 
dades de consultoría 1.1, 13.2 y 14.5 para más información sobre la organización, sus 
productos y sus objetivos.] Su diseño debe tomar la forma de un informe escrito para el 
dueño de la cadena, Bill Berry. Asegúrese de indicar qué estadísticas supervisará y por 
qué es importante que Marathón Vitamin Shops las conozca. 

6. FilmMagic, una cadena de tiendas de renta de video introducida en el capítulo 7, está 
experimentando con agregar un nuevo servicio basado en Web a su tienda (similar a 
www.netflix.com] que podría, por una cuota mensual, permitir a clientes escoger una 
lista de DVDs, prepararlos para enviarlos a su casa y regresarlos en un sobre prepagado 
cuando los hayan visto. Basado en lo que sabe de FilmMagic, escriba una política de pri¬ 
vacidad corporativa que funcionaría bien en su sitio Web recientemente propuesto. 
Cree una pantalla de prototipo (con un paquete de gráficos o con un procesador de 
texto) que incluya lenguaje apropiado, fuentes e iconos para mostrar cómo aparecerá 
su política como una página en el sitio Web de FilmMagic. 

7. Ayman's Office Supplies Company tenía un nuevo sistema de información reciente¬ 
mente instalado para ayudar a sus gerentes con el inventario. Hablando con los geren¬ 
tes, observa que parecían enfadados con la salida del sistema, la cual es una serie de 
pantallas que muestran el inventario actual, direcciones del cliente y proveedor, etc. 
Se necesita acceder a todas las pantallas a través de varios comandos especiales y el uso 
de una contraseña. Los gerentes tienen varias opiniones sobre el sistema pero no tienen 
ninguna forma sistemática de evaluarlo. 

a. Invente una lista de control o formulario que ayuden a los gerentes de Ayman a 
evaluar las utilidades de un sistema de información. 
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b. Sugiera una segunda forma de evaluar el sistema de información. Compárela con 
lo que hizo en el problema 7a. 

8. Visite varios ISP tal como Verio, AT&T y otros. Investigue qué clase de características 
de análisis de tráfico Web ofrecen a los administradores Web cuyos sitios Web organi¬ 
zan. Haga una lista de informes y estadísticas que ofrecen y escriba esta lista como 
parte de la evaluación de una propuesta de desarrollo de sistemas de aplicación de co¬ 
mercio electrónico. 


PROYECTO DE GRUPO 

1. Visite seis sitios Web diferentes. Escoja un sitio Web de cada una de las categorías si¬ 
guientes: 

a. Un portal, tal como Yahoo! o Excite. 

b. Una página de noticias, tal como ABC News o New York Times. 

c. Una compañía de software. 

d. Un sitio Web universitario. 

e. Un sitio Web oficial de un equipo deportivo o una compañía de teatro. 

f. Un sitio Web de un continente que no sea en el que vive. 

Evalúe cada uno desde un enfoque de utilidad de información. 

Prepare una tabla similar a la de la figura 17.13 con sus respuestas. Deberá haber 
un renglón para cada uno de los seis sitios Web. Indique el URL del sitio Web. Cuando 
crea que necesita análisis de tráfico Web para evaluar una de las utilidades, declárelo en 
la celda adecuada de la tabla. 
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SEM.PER REDUNDATE 


Mack Roe se dirige hacia el escritorio de Anna, donde también se encuentra Chip, y dice: 
"Se ha probado el último programa y se ha incorporado a la prueba del sistema. Los resul¬ 
tados indican que el sistema está terminado. Todos los programas y subsistemas funcionan 
de la manera como se planeó. Todo el sistema se revisó en detalle. Las pruebas han sido ex¬ 
tensas y precisas, y todos los problemas y errores se han resuelto de manera satisfactoria. He 
revisado todo lo que se debía entregar, y todo se desarrolló en los programas. Los dejo que 
lo instalen y que después celebren". 

"[Esto es grandioso!", exclama Anna cuando Mack se aleja. "Hemos estado esperando 
mucho este momento. Ahora tenemos la tarea de instalar el sistema. Ya revisé con Mike 
Crowe, y ya llegó todo el hardware y está instalado. Las computadoras se conectaron en una 
instalación de estrella, y ya se instaló el software de red. ¿Por qué no hacemos una lista de 
las tareas que debemos realizar?" 

"De acuerdo", responde Chip. "Tenemos que capacitar a los usuarios en el manejo del 
sistema. Seria bueno ofrecer primero una capacitación general, y luego la capacitación espe¬ 
cífica para cada usuario. Tal vez sea necesario que capacitemos a varias personas —al usua¬ 
rio y a alguien que lo sustituya— para cada operación específica." 

"Me parece bien", contesta Anna, "pero no creo que sea conveniente un sustituto para 
Paige Prynter. No creo que a ella le agrade la idea". 

"Hablando de sustitución", agrega Chip, "¿qué hay de la creación de respaldos de los ar¬ 
chivos maestros y otros archivos del sistema? Deberíamos diseñar algún procedimiento au¬ 
tomatizado para crear estas copias". 

"Sí", responde Anna. "También debemos ocuparnos de la seguridad del sistema: quién 
puede acceder a los datos, y quién puede actualizar los diversos elementos de la base de 
datos." 

"De acuerdo", subraya Chip. "Otro pendiente es convertir al nuevo formato los archi¬ 
vos de producción del sistema anterior. No necesitamos volver a teclear todos los registros 
de los archivos maestros de hardware y software." 

"¿Por qué no encargamos a uno de los programadores que escriba un programa único 
que convierta al nuevo formato cada uno de los archivos del formato viejo?", sugiere Anna. 
"Los índice se podrían actualizar automáticamente, y los campos adicionales se podrían ini- 
cializar con espacios o ceros." 

Los programadores terminan en poco tiempo los programas de conversión de archivos. 
Los nuevos archivos se crean y su exactitud se verifica con gran detalle. Este esfuerzo se ve 
recompensado con nuevos archivos maestros que contienen todos los registros necesarios 
con información correcta. 

La capacitación se programa para comenzar en el Centro de Información. Hy Perteks 
tiene mucha disposición para dedicar tiempo a la instalación del software y a impartir las se¬ 
siones de capacitación. Chip y Anna se alternan para dar capacitación en las respectivas 
áreas del sistema que crearon. 

Al finalizar las sesiones de capacitación, la última tarea consiste en la conversión del sis¬ 
tema viejo al nuevo. Se elige el método de fases como el mejor enfoque. Primero se instalan 
los programas en el hardware. Los registros se actualizan con información para los elemen¬ 
tos adicionales que se incluyeron en el diseño del sistema. 

A continuación, se instalan los programas de actualización del software. Una vez más, 
se introducen actualizaciones a los registros de los archivos maestros. Cuando los registros 
contienen toda la información necesaria, se instalan las pantallas de consulta. Por último, se 
agregan al sistema los programas de informes y menús. 
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"La instalación es un éxito redondo", se regocija Chip. "Todo funciona correctamente, 
sin un error en el sistema. [Toco madera! ¿Te han comentado algo los usuarios?" 

"Sí", responde Anna. "Están felices y aliviados por contar con su nuevo sistema. Mike 
Crowe ya empezó a utilizar la característica de mantenimiento preventivo, y puso a sus es¬ 
tudiantes a que le ayudaran a realizarlo en un salón a la vez. Cher y Dot han ejecutado las 
diversas pantallas y varias veces han elogiado lo fácil que es realizar sus tareas. Visité a Paige 
Prynter, y me pidió que le sugiriera qué hacer con todo el tiempo libre que le queda." 

Los analistas sonríen. Chip dice: "En realidad ha sido bueno trabajar en este proyecto". 

"Así es", responde Anna. "El mejor sistema que hemos creado aquí en la CPU." 

"También he aprendido mucho de la universidad en mi breve estancia aquí. Es un buen 
lugar para trabajar", dice Chip con filosofía. 

"Y si recuerdas nuestro lema, debes hacerlo bien", responde Anna. "Semper redundóle ", 
le dice a Chip. 

"Sí, lo veo en todos los membretes. Sin embargo, admito que nunca tomé latín en la es¬ 
cuela. ¿Qué significa este lema?", pregunta Chip 

"¡Respalda siempre!", dice Anna con seguridad. 


EJERCICIOS 

E-l. Dé su opinión en un párrafo acerca de por qué se utilizó la configuración en estrella. 
¿Tiene algo que ver el hecho de que los estudiantes estén en diferentes salones? 

E-2. Describa los procedimientos que deben diseñarse para crear archivos de respaldo de 
manera automática. Explique en un párrafo los pros y contras de estos procedimientos. 

E-3. Mencione las medidas de seguridad que deben tomarse para impedir que personas no 
autorizadas utilicen el sistema de cómputo. 

E-4. Explique en un párrafo por qué se utilizaría una conversión en fases para instalar el 
sistema de cómputo. 
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ANÁLISIS Y DISEÑO DE SISTEMAS 
ORIENTADO A OBJETOS USANDO 
EL LENGUAJE UNIFICADO 
DE MODELACIÓN (UML) 



OBJETIVOS DE APRENDIZAJE 

Una vez que haya dominado el material de este capítulo, podrá: ; . - 

1 Entender lo que es el análisis y diseño de sistemas orientados a objetos y apreciar su utilidad 

2. Comprender los conceptos del lenguaje unificado de modelación (UML), el enfoque estándar pará . ; 
-■T-.jM nripdelar un sistema en el mundo orientado a objetos. 

3. Aplicar los pasos usados en UML para dividir el sistema en un modeló de casos de uso y después 

en un modelo de clases. . 

4. Diagramar sistemas con el conjunto de herramientas de UML con el fin de que se puedan describir 

y diseñar apropiadamente. ...... i'- 

5. Documentar y comunicar el sistema orientado a objetos recién modelado. 


TI desafío di 1 desarrollar nuevos yJster.'lis de información para aplicaciones de comercio 
ekictronico, inrílilmliricas y poctáti:les.en.entorno 1 » económicos, legales, sociales v lisíeos diná¬ 
mico»; requ’ere nue\as técnii;.is ile análisis- y r¡Ne:To. I':\ análisis y diseño orientado ;i objetos 
piixJr olreccr in enfoque que-habilite los.métodos lógicos,, rápidos V minuub.sos necesarios 
par.', kear nuevo 1 ; «-islemns en .respuesta ai cambiante entorno He un ne;.;ocio. la-s liVnicas 
orientad:!; a ojnVing son '.ideciiüda*'. i.'n siíiuciones en une los sistem.:.; úe iüFon-natíón com¬ 
plicados requieren de mantenimiento, adaptación y rediseño continuos. 

Los sistemas orientados a objetos describen las entidades como objetos. Los objetos son 
parte de Tin concepto general denominado clases. El deseó de poner elementos en las i:lases 
no es nuevo. La descripción del mundo como se ha hecho con Jos animales, vegetales y mi¬ 
nerales es un ejemplo de clasificación, aunque tiene pocas bases científicas. El enfoque- cien¬ 
tífico incluye clases de animales [como mamíferos¡ y después divide las clases en subclases 
[como animales ovíparos y marsupiales}.;/. fe'Ks-'-ft'iy. 

La idea de las clases es tener un punto de referencia y describir las similitudes p ilile- 
rencias que un objeto específico posee con respecto a los miembros de su propia clase. Con 
ello, es más eficaz para alguien decir: "El oso koala es un marsupial [o animal con bolsa) 
con una cabeza redonda y grande y orejas peludas", que.describir un oso koala con todas sus 
características como mamífero. Es más eficaz describir características, apariencia e incluso 
la conducta de esta manera. Cuando se oye la palabra reiitilizoblc en el mundo orientado a 
objetos, significa que uñó puede ser más eficaz, debido a que no esmecesario describir un ob¬ 
jeto desde el principio cada vez que se necesite para el desarrolló dé software, t í/;/: 
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Cuando se introdujo por primera vez el enfoque orientado a objetos, sus defensores 
mencionaron la reusabilidad de objetos como el principal beneficio de su enfoque. Es evi¬ 
dente que el reciclaje de partes de programas debe reducir los costos de desarrollo en los sis¬ 
temas computacionales. Esto ya ha demostrado su eficacia en el desarrollo de GUIs y bases 
de datos. Aunque la reusabilidad es la meta principal, el mantenimiento de sistemas tam¬ 
bién es muy importante, y al crear objetos que contienen datos y código de programación, 
un cambio en un objeto tiene un impacto mínimo en otros objetos. 

En este capítulo presentamos el lenguaje unificado de modelación (UML, por sus siglas 
en inglés], el estándar de la industria para modelar sistemas orientados a objetos. El conjun¬ 
to de herramientas UML incluye diagramas que permiten visualizar la construcción de un 
sistema orientado a objetos. El UML es una herramienta poderosa que puede mejorar enor¬ 
memente la calidad del análisis y diseño de sistemas, y contribuir por tanto a crear sistemas 
de información de alta calidad. 

Con el uso iterativo de UML es posible lograr una mayor comprensión entre los equi¬ 
pos de negocios y los de TI en relación con los requerimientos del sistema y los procesos que 
necesitan realizarse en este último para cumplir dichos requerimientos. En cada iteración 
el diseño del sistema toma una apariencia más detallada hasta que las cosas y relaciones en el 
sistema se definen con claridad y precisión en los documentos de UML. Las características 
más importantes de cada fase se podrían definir inicialmente, y después incorporarse en el 
proceso de desarrollo. Aunque el proceso es iterativo, es importante que quede tan comple¬ 
to como sea posible desde el principio. 

Al terminar el análisis y diseño, se tendría un conjunto preciso y detallado de especifi¬ 
caciones para las clases, procesos y otros artefactos del sistema, lo cual contribuye a evitar el 
costo de volver a codificar a causa de una pobre planeación inicial. Un artefacto es un tér¬ 
mino general que se utiliza para describir cualquier pieza de información usada o producida 
al desarrollar sistemas. Podría ser un diagrama, texto descriptivo, instrucciones de usuario, 
métodos del código, programas o cualquier otro componente del sistema. 


CONCEPTOS ORIENTADOS A OBJETOS 

La programación orientada a objetos difiere de la programación por procedimientos tradi¬ 
cional, pues examina los objetos que son parte de un sistema. Cada objeto es una represen¬ 
tación en computadora de alguna cosa o evento real. En esta sección se presentan descrip¬ 
ciones generales de los principales conceptos orientados a objetos de las clases, la herencia y 
los objetos,. En secciones posteriores de este mismo capítulo se ofrece más información de 
otros conceptos de UML. 


OBJETOS 

Los objetos son personas, lugares o cosas que son relevantes para el sistema bajo análisis. Los 
objetos podrían ser clientes, artículos, pedidos, etc. Los objetos también podrían ser panta¬ 
llas GUI o áreas de texto en la pantalla. 


CLASES 

Los objetos se representan y agrupan en clases que son óptimas para reutilizarse y darles 
mantenimiento. Una clase define el conjunto de atributos y comportamientos compartidos 
por cada objeto de la clase. Por ejemplo, los registros de los estudiantes en la sección de un 
curso almacenan información similar para cada estudiante. Se podría decir que los estudian¬ 
tes constituyen una clase. Los valores podrían ser diferentes para cada estudiante, pero el tipo 
de información es el mismo. Los programadores deben definir las diversas clases en el pro¬ 
grama que escriben. Cuando el programa corre, los objetos se pueden crear a partir de la 
clase establecida. El término instanciar se usa cuando un objeto se crea a partir de una cla¬ 
se. Por ejemplo, un programa podría instanciar a un estudiante llamado Peter Wellington co¬ 
mo un objeto de la clase denominada estudiante. 
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Lo que hace a la programación orientada a objetos, y por consiguiente al análisis y dise¬ 
ño orientado a objetos, diferente de la programación clásica, es la técnica de poner todos los 
atributos y métodos de un objeto en una estructura independiente, la propia clase. Ésta es 
una situación común en el mundo físico. Por ejemplo, un paquete con harina para pastel 
empacado es similar a una clase ya que contiene los ingredientes y las instrucciones para 
mezclar y hornear el pastel. Un suéter de lana es similar a una clase porque incluye una eti¬ 
queta con instrucciones del cuidado que advierten que se debe lavarlo a mano y ponerlo a 
secar extendido. 

Cada clase debe tener un nombre que la distinga de todas las demás. Los nombres de 
clase normalmente son sustantivos o frases cortas y empiezan con una letra mayúscula. En 
la figura 18.1 la clase se llama RentaAuto. En el UML, una clase se representa como un rec¬ 
tángulo. El rectángulo contiene otras dos características importantes: una lista de atributos y 
una serie de métodos. Estos elementos describen una clase, la unidad de análisis que es una 
parte principal de lo que llamamos análisis y diseño orientado a objetos. 

Un atributo describe alguna propiedad de todos los objetos de la clase. Observe que la 
clase RentaAuto posee los atributos tamaño, color, marca y modelo. Todos los automóviles 
poseen estos atributos, pero los atributos de cada automóvil tendrán diferentes valores. Por 
ejemplo, un automóvil puede ser azul, blanco o de algún otro color. Más adelante demostra¬ 
remos que es posible serrnás específico acerca del rango de valores para estas propiedades. 
Al especificar atributos, normalmente la primera letra es minúscula. 

Un método es una acción que se puede solicitar a cualquier objeto de la clase. Los 
métodos son los procesos que una clase sabe cómo realizar. Los métodos también se lla¬ 
man operaciones. La clase RentaAuto podría tener los siguientes métodos: inicioRen- 
ta(), entregaAutof ) y servicio( ). Al especificar métodos, normalmente la primera letra 
es minúscula. 


HERENCIA 

Otro concepto importante de los sistemas orientados a objetos es la herencia. Las clases 
pueden tener hijos; es decir, una clase se puede crear a partir de otra clase. En el UML, la 
clase original —o madre— se conoce como clase base. La clase hija se denomina clase deri¬ 
vada. Ésta se puede crear de tal manera que herede todos los atributos y comportamientos 
de la clase base. Sin embargo, una clase derivada podría tener atributos y comportamien¬ 
tos adicionales. Por ejemplo, podría haber una clase Vehículo para una compañía de renta 
de automóviles que contenga atributos como tamaño, color y marca. Como se muestra en 
la figura 18.2, las clases derivadas podrían ser Automóvil o Camioneta. 

La herencia reduce el trabajo de la programación usando fácilmente objetos comunes. 
El programador sólo necesita declarar que la clase Automóvil hereda de la clase Vehículo y 
después proporcionar cualesquier detalles adicionales sobre nuevos atributos 0 comporta¬ 
mientos que sean únicos para un automóvil. Todos los atributos y comportamientos de la 
clase Vehículo son automática e implícitamente parte de la clase Automóvil y no requieren 
ninguna programación adicional. Esto le permite al analista definir una sola vez pero usar 
muchas veces y es similar a los datos que están en la tercera forma normal, definidos una so¬ 
la vez en una tabla de la base de datos (como se analizó en el capítulo 13). 






Diagrama de ciases que muestra 
la. herencia. Automóvil y 
Camioneta son ejemplos 
específicos de vehículos y 
heredan las características de la 
clase más general, Vehículo. 



En la figura 18.2, los atributos son precedidos por signos de resta y los métodos por sig¬ 
nos de suma. Explicaremos esto con mayor detalle más adelante en este capítulo, pero por 
ahora tome nota de que los signos de resta significan que estos atributos son privados (no 
compartidos con otras clases] y estos métodos son públicos (podrían ser invocados por otras 
clases]. 

La reutilización de código de programa ha sido parte del desarrollo de sistemas y len¬ 
guajes de programación estructurados (como COBOL] durante muchos años y ha habido 
subprogramas que encapsulan datos. Sin embargo, la herencia es una característica que sólo 
se encuentra en los sistemas orientados a objetos. 


TARJETAS CRC Y PENSAMIENTO EN OBJETOS 

Ahora que hemos cubierto los conceptos fundamentales del análisis y diseño de sistemas 
orientados a objetos, necesitamos examinar las formas de crear clases y objetos a partir de 
los problemas de negocios y sistemas que estamos enfrentando. Una forma de empezar a es¬ 
tablecer el enfoque orientado a objetos es comenzar a pensar y hablar de esta nueva forma. 
Un enfoque conveniente es desarrollar tarjetas CRC. 

CRC significa clase, responsabilidades y colaboradores. El analista puede usar estos 
conceptos cuando empiece a hablar del, o a modelar el, sistema desde una perspectiva 
orientada a objetos. Las tarjetas CRC se usan para representar las responsabilidades de las 
clases y sus interacciones. Los analistas crean las tarjetas con base en escenarios que delinean 
los requerimientos del sistema. Estos escenarios modelan el comportamiento del sistema 
que se está estudiando. Si se van a utilizar en grupo, las tarjetas CRC se pueden crear ma¬ 
nualmente en pequeñas tarjetas de notas o se pueden crear en una computadora. 
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_H ombre de la c lase: C'ur ge 
_Superclases: 

Snhdase s: 

Rftsponsab fHitedos 

Agregar un nuev o curar, 
- Caml, ' ar l nform ^ n del curso 
- nesplpgar información del cur^o 


_Colaboradoras 

-Departamento^. 


Pensamiento del objeto 

Conozco d núrnerodejnl curso 
_ Conozco mi descripción 
_£onozco mi número de crédito 


Propiedad 

Número de’ curso 

. Descripción del curso 
Créditos 


Nombre de la clase: Libro de texto. 

Supeiciases:: : 


Subclases: 

Responsabilidades 

Colaboradores 

Pensamiento del objeto 

Propiedad 

Aaretiar un nuevo libro de texto 

Curso 

Conozco mi ÍSE3M 

ISBN 

Cambiar información del libro de texto 


i Conozco tni autor 

Autor 

Encontrar información del libro de texto 


Conozco mi título 

Título 

Eliminar libros de texto obsoletos 


Conozco mi edición 

, Edición 



Conozco mi editor 

| Editor 



5é si soy solicitado 

| Solicitado 


MombredeJa clase: Tarea 
_Superclas es: 

.. Subcl ases : 

..Responsabilidades 


Colaboradores 

Curso 


1 Pensamiento del objeto 

Conozco e l númemdenú ta^ a 
Co nozco mi descripción 
. Conozco cuántos (juntos rejwsa ito 
. Cono ^o cuándo Asbo terminar 


1 Prtp(td»a . I 

Húmero de la tarea I 

fescripelén Ai la tarja 

Puntos 

Fecha de vencimiento 




HMi 


oücijIü taífciaa oñro para las 
ofertas de cursos muestran la 
manera en que los analistas 
completan los detalles para las 
clases, responsabilidades y 
colaboradores, así como también 
para los enunciados de 
pensamiento del objeto y los 
nombres de propiedad. 




Las cuatro tarjetas CRC descritas en la figura 18.3 muestran cuatro clases para ofertas 
de cursos. Observe que en una clase denominada Curso, el analista de sistemas se refiere 
a cuatro colaboradores: el departamento, el libro de texto, la tarea del curso y el examen 
del curso. A continuación estos colaboradores se describen como clases en las otras tarje¬ 
tas CRC. 
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Posteriormente, las responsabilidades mencionadas se convertirán en lo que en UML se 
denomina métodos. Los enunciados del pensamiento del objeto parecen elementales, pero 
tienen un tono informal para animar a los grupos de analistas a describir tantos enunciados 
como sea posible durante una sesión de CRC. Como se muestra en el ejemplo, todo el diá¬ 
logo durante una sesión de CRC se lleva a cabo en primera persona, para que incluso el li¬ 
bro de texto hable: "Conozco mi ISBN". "Conozco a mi autor". En consecuencia, estos 
enunciados se pueden usar para describir los atributos en UML. Estos atributos se pueden 
llamar por sus nombres de variables, como edición y editor. 


CONCEPTOS Y DIAGRAMAS DEL LENGUAJE UNIFICADO 
DE MODELACIÓN (UML) 

Vale la pena investigar y entender el enfoque de UML por su gran aceptación y uso. UML 
proporciona un conjunto estandarizado de herramientas para documentar el análisis y di¬ 
seño de un sistema de software. El conjunto de herramientas de UML incluye diagramas 
que permiten a las personas visualizar la construcción de un sistema orientado a objetos, 
similar a la forma en que un conjunto de planos permite a las personas visualizar la cons¬ 
trucción de un edificio. Ya sea que usted esté trabajando independientemente o con un 
equipo grande de desarrollo de sistemas, la documentación que crea con UML proporcio¬ 
na un medio eficaz de comunicación entre el equipo de desarrollo y el equipo de negocios 
en un proyecto. 

Como se ilustra en la figura 18.4, UML consiste de cosas, relaciones y diagramas. Los 
primeros componentes, o elementos principales, de UML se denominan cosas. Quizá usted 
prefiera otra palabra, como objeto, pero en UML se denominan cosas. Las cosas estructura¬ 
les son más comunes. Las cosas estructurales son clases, interfaces, casos de uso y muchos 
otros elementos que proporcionan una forma de crear modelos. Las cosas estructurales per¬ 
miten al usuario describir relaciones. Las cosas de comportamiento describen cómo funcio¬ 
nan las cosas. Las interacciones y las máquinas de estado son ejemplos de cosas de compor¬ 
tamiento. Las cosas de agrupamiento se usan para definir límites. Un ejemplo de una cosa 
de agrupamiento es un paquete. Por último, tenemos las cosas de anotación, para que poda¬ 
mos agregar notas a los diagramas. 

Las relaciones son el pegamento que une las cosas. Es útil considerar a las relaciones de 
dos formas. Las relaciones estructurales se usan para enlazar las cosas en los diagramas es¬ 
tructurales. Las relaciones estructurales incluyen dependencias, agregaciones, asociaciones y 
generalizaciones. Por ejemplo, las relaciones estructurales muestran herencia. Las relaciones 
de comportamiento se usan en los diagramas de comportamiento. Los cuatro tipos básicos de 
relaciones de comportamiento son: comunica, incluye, extiende y generaliza. 

Hay dos tipos principales de diagramas en UML: diagramas estructurales y diagramas 
de comportamiento. Por ejemplo, los diagramas estructurales se usan para describir las re¬ 
laciones entre las clases. Incluyen diagramas de clases, diagramas de objetos, diagramas de 
componentes y diagramas de despliegue. Por otro lado, los diagramas de comportamiento 
se pueden usar para describir la interacción entre las personas (denominadas actores en 
UML] y la cosa a la que nos referimos como caso de uso, o cómo usan los actores el siste¬ 
ma. Los diagramas de comportamiento incluyen diagramas de caso de uso, diagramas de 
secuencias, diagramas de colaboración, diagramas de gráfico de estado y diagramas de ac¬ 
tividades. 

En el resto de este capítulo analizaremos primero el modelado de casos de uso, la base 
para todas las técnicas de UML. Después, veremos cómo se emplea un caso de uso para de¬ 
rivar actividades, secuencias y clases —los diagramas de UML que más se utilizan—. Debido 
a que todos los libros se dedican a la sintaxis y uso de UML (el documento de especificacio¬ 
nes de UML contiene alrededor de 800 páginas], sólo proporcionamos un breve resumen 
de los aspectos más valiosos y comúnmente usados de UML. 
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V'ísia general üe UiviLy bub 
componentes: cosas, relaciones 
y diagramas. 


Categoría UML 

Elementos de UML 

Detalles específicos de UML 

Cosas 

Cosas estructurales 

Clases 

Interfaces 

Colaboraciones 

Casos de uso 

Clases activas 

Componentes 

Nodos ' • 7 lÚ'f' ' i 


Cosas de comportamiento 

Interacciones 

Máquinas de estado 


Cosas de agrupamiento 

Paquetes xLfv'LLLj 


Cosas de anotación 

Notas 

Relaciones 

Relaciones estructurales 

Dependencias;:)-;; 

Agregaciones 

Asociaciones 

Generalizaciones 


Relaciones de comportamiento 

Comunica 

Incluye 

Extiende 

Generaliza 

Diagramas 

Diagramas estructurales 

Diagramas de clase 

Diagramas de componentes 
Diagramas de despliegue 


Diagramas de comportamiento 

Diagramas de caso de uso 
Diagramas de secuencias 
Diagramas de colaboración 
Diagramas de gráfico de estado 
Diagramas de actividades 


Los seis diagramas de UML que más se utilizan son: 

1. Diagrama de caso de uso, que describe cómo se usa el sistema. Los analistas empiezan 
con un diagrama de caso de uso. 

2. Escenario de caso de uso (aunque técnicamente no es un diagrama), es una descripción 
verbal de las excepciones para el comportamiento principal descrito por el caso de uso 
principal. 

3. Diagrama de actividades, ilustra el flujo general de actividades. Cada caso de uso podría 
crear un diagrama de actividades. 

4. Diagramas de secuencias, muestran la secuencia de actividades y las relaciones de las 
clases. Cada caso de uso podría crear uno o más diagramas de secuencias. Una alterna¬ 
tiva para un diagrama de secuencias es un diagrama de colaboración, el cual contiene la 
misma información en formato diferente. 

5. Diagramas de clases, muestran las clases y las relaciones. Los diagramas de secuencias se 
usan (junto con las tarjetas CRC) para determinar las clases. Un vastago de un diagra¬ 
ma de clases es un diagrama gen/esp (que significa generalízación/especialización). 

6. Diagramas de gráfico de estado, muestra las transiciones de estado. Cada clase podría 
crear un diagrama de gráfico de estado, el cual es útil para determinar los métodos de la 
clase. 


En la figura 18.5 se ilustra cómo se relacionan entre sí estos diagramas. En las siguien¬ 
tes secciones discutiremos cada uno de estos diagramas. 
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MODELADO DE CASOS DE USO 

El UML está basado fundamentalmente en una técnica de análisis orientada a objetos cono¬ 
cida como modelado de casos de uso, en la cual la palabra uso se pronuncia como sustanti¬ 
vo en lugar de verbo. Un modelo de caso de uso describe lo que hace un sistema sin descri¬ 
bir cómo lo hace; es decir, es un modelo lógico del sistema. [Los modelos lógico o 
conceptual se introdujeron en el capítulo 7.] El modelo de caso de uso refleja la vista del 
sistema desde la perspectiva de un usuario fuera del sistema [es decir, los requerimientos 
del sistema). El UML se puede usar para analizar el modelo de caso de uso y para derivar 
objetos del sistema y sus interacciones entre sí y con los usuarios del sistema. Usando las 
técnicas de UML, analiza más a fondo los objetos y sus interacciones para derivar compor¬ 
tamiento del objeto, atributos y relaciones. 
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Un analista desarrolla casos de uso en colaboración con los expertos del negocio que 
ayudan a definir los requerimientos del sistema. El modelo de caso de uso proporciona 
medios eficaces de comunicación entre el equipo del negocio y el equipo de desarrollo. Un 
modelo de caso de uso divide la funcionalidad del sistema en comportamientos, servicios y 
respuestas (los casos de uso) que son significativos para los usuarios del sistema. 

Desde la perspectiva de un actor (o usuario], un caso de uso debe producir algo que es 
de valor. Por lo tanto, el analista debe determinar lo que es importante para el usuario y re¬ 
cordar incluirlo en el diagrama de caso de uso. Por ejemplo, ¿una contraseña está introdu¬ 
ciendo algo de valor para el usuario? Se podría incluir si el usuario tiene una preocupación 
sobre la seguridad o si es crítico para el éxito del proyecto. 


SÍMBOLOS DEL CASO DE USO 

Un diagrama de caso de uso contiene el actor y símbolos de caso de uso, junto con líneas de 
conexión. Los actores son parecidos a las entidades externas; existen fuera del sistema. El 
término actor se refiere a un papel particular de un usuario del sistema. Por ejemplo, un ac¬ 
tor podría ser un empleado, pero también podría ser un cliente en el almacén de la compa¬ 
ñía. Aunque quizás es la misma persona en el mundo real, se representa como dos símbolos 
diferentes en un diagrama de caso de uso, debido a que la persona interactúa con el sistema 
en diferentes papeles. El actor existe fuera del sistema e interactúa con éste de una forma 
específica. Un actor puede ser un humano, otro sistema o un dispositivo tal como un tecla¬ 
do, módem o conexión Web. Los actores pueden iniciar una instancia de un caso de uso. Un 
actor podría interactuar con uno o más casos de uso y viceversa. 

Los actores se podrían dividir en dos grupos. Los actores principales proporcionan datos 
o reciben información del sistema. Los actores secundarios ayudan a mantener el sistema en 
ejecución o proporcionan ayuda. Éstas son las personas que operan el centro de atención 
telefónica, los analistas, programadores, etcétera. 

Un caso de uso proporciona a los desarrolladores una visión de lo que quieren los usua¬ 
rios. No contiene detalles técnicos o de implementación. Podemos pensar en un caso de uso 
como una secuencia de transacciones en un sistema. El modelo de caso de uso se basa en las 
interacciones y relaciones de casos de uso individuales. 

Un caso de uso siempre describe tres cosas: un actor que inicia un evento; el evento que 
activa un caso de uso, y el caso de uso que desempeña las acciones activadas por el evento. 
En un caso de uso, un actor que usa el sistema comienza un evento que empieza una serie 
relacionada de interacciones en el sistema. Los casos de uso se utilizan para documentar una 
sola transacción o evento. Un evento es una entrada al sistema que pasa en un tiempo y lu¬ 
gar específicos y ocasiona que el sistema haga algo. 

Es mejor crear pocos casos de uso en lugar de muchos. Con frecuencia no se incluyen 
consultas e informes; 20 casos de uso (y no más de 40 o 50) son suficientes para un sistema 
grande. Los casos de uso también se podrían anidar, si es necesario. Puede incluir un caso de 
uso en varios diagramas, pero el caso de uso real sólo se define una vez en el depósito o dic¬ 
cionario. Un caso de uso se nombra con un verbo y un sustantivo. 


RELACIONES DEL CASO DE USO 

Las relaciones activas se denominan como relaciones de comportamiento y se emplean 
principalmente en los diagramas de caso de uso. Hay cuatro tipos básicos de relaciones de 
comportamiento: comunica, incluye, extiende y generaliza. Observe que todos estos térmi¬ 
nos son verbos de acción. La figura 18.6 muestra las flechas y líneas usadas para diagramar 
cada uno de los cuatro tipos de relaciones de comportamiento. Las cuatro relaciones se des¬ 
criben a continuación. 


Comunica La relación de comportamiento comunica se usa para conectar a un actor con 
un caso de uso. Recuerde que la tarea del caso de uso es dar alguna clase de resultado que es 
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Relación 


Símbolo 


Significado 


Comunica 

Incluye 

Extiende 


«incluir» 


Un actor se conecta a un caso do uso usando una línea sin puntas ., 
de flecha. 

Un caso de uso contiene un comportamiento que es más común que 
otro caso de uso. La flecha apunta al caso de uso común. 


•L':' «extender» r : «L ; 

:■-- — --■ 


uso 


básico. La flecha apunta desdé el casó do.uso extendido hacia el básico. 


Generaliza 


Una "cosa" de UML es más general que otra "cosa". La flecha 
apunta a la "cosa" general. 


benéfico para el actor en el sistema. Por lo tanto, es importante documentar estas relaciones 
entre actores y casos de uso. En nuestro ejemplo, un Estudiante se comunica con Matricu¬ 
larse en el curso. En los diagramas de caso de uso de la figura 18.7 se muestran ejemplos de 
algunos componentes de un ejemplo de matriculación del estudiante. 


Algunos componentes de los 
diagramas de caso de uso 
muestran actores, casos de uso 
y relaciones para un ejemplo de 1 
matriculación de un estudiante. 


Incluye La relación incluye describe la situación en que un caso de uso contiene un com¬ 
portamiento que es común para más de un caso de uso. Es decir, el caso de uso común se in¬ 
cluye en otros casos de uso. Una flecha punteada que apunta al caso de uso común indica la 
relación incluye. Un ejemplo seria un caso de uso Pago de cuotas del estudiante que se in¬ 
cluye en Matricularse en el curso y Arreglar residencia estudiantil, debido a que en ambos 


Cuatro tipos de relaciones 
además de flechas y líneas de 
comportamiento de UML usadas 
para representar las relaciones. 
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casos los estudiantes deben pagar sus cuotas. Esto se podría usar por varios casos de uso. La 
flecha apunta hacia el caso de uso común. 

Extiende La relación extiende describe la situación en la que un caso de uso posee el com¬ 
portamiento que permite al nuevo caso de uso manejar una variación o excepción del caso 
de uso básico. Por ejemplo, el caso de uso extendido Seguro médico del estudiante extiende 
el caso de uso básico Pago de cuotas del estudiante. La flecha va del caso de uso extendi¬ 
do al básico. 

Generaliza La relación generaliza implica que una cosa es más típica que otra. Esta rela¬ 
ción podría existir entre dos actores o dos casos de uso. Por ejemplo. Estudiante de tiempo 
parcial generaliza un Estudiante. Del mismo modo, algunos empleados universitarios son 
profesores. La flecha apunta a la cosa general. 


DESARROLLO DE DIAGRAMAS DE CASO DE USO 

El caso de uso principal (también denominado ruta principal o ruta feliz) consiste de un 
flujo estándar de eventos en el sistema que describe un comportamiento estándar del siste¬ 
ma. El caso de uso principal representa la realización normal, esperada y exitosa del caso de 
uso. Las variaciones o excepciones (también denominadas rutas alternativas) también se 
pueden diagramar y describir. 

Al diagramar un caso de uso, empiece pidiendo a los usuarios que mencionen todo lo 
que el sistema debe hacer para ellos. Esto se puede hacer con entrevistas, en una sesión 
de diseño conjunto de aplicaciones (JAD) (como se describió en el capítulo 4) o a través de 
otras sesiones de equipo facilitadas. Escriba quién está involucrado con cada caso de uso y 
las responsabilidades o servicios que el caso de uso debe proporcionar a los actores u otros 
sistemas. En las fases iniciales, ésta podría ser una lista parcial que se extiende en las últimas 
fases del análisis. Use los siguientes lineamientos: 

1. Revise las especificaciones del negocio e identifique los actores en el dominio del 
problema. 

2. Identifique los eventos de alto nivel y desarrolle los casos de uso principales que descri¬ 
ben dichos eventos y cómo los inician los actores. Examine cuidadosamente los papeles 
jugados por los actores para identificar todos los posibles casos de uso principales ini¬ 
ciados por cada actor. No se necesita mostrar los casos de uso con poca o ninguna inte¬ 
racción del usuario. 

3. Revise cada caso de uso principal para determinar las posibles variaciones de flujo a tra¬ 
vés del caso de uso. Con este análisis, establezca las rutas alternativas. Debido a que el 
flujo de eventos normalmente es diferente en cada caso, busque actividades que po¬ 
drían tener éxito o fallar. También busque cualesquier ramas en la lógica de caso de uso 
en que son posibles resultados diferentes. 

Si se ha creado un diagrama de flujo de datos de nivel contexto, puede ser un punto 
de partida para crear un caso de uso. Las entidades externas son actores potenciales. En¬ 
tonces examine el flujo de datos para determinar si iniciaría un caso de uso o sería produci¬ 
do por uno. 

La figura 18.8 es un ejemplo de caso de uso de matriculación del estudiante a una uni¬ 
versidad. Observe que sólo se representan las funciones más importantes. El caso de uso 
Agregar estudiante no indica cómo agregar estudiantes, que sería el método de implemen- 
tación. Los estudiantes se podrían agregar personalmente, usando Web, usando un teléfono 
de tonos o cualquier combinación de estos métodos. El caso de uso Agregar estudiante in¬ 
cluye el caso de uso Verificar identidad para verificar la identidad del estudiante. El caso de 
uso Comprar libro de texto extiende el caso de uso Matricularse en la clase y podría ser 
parte de un sistema para matricular a los estudiantes en un curo en línea. 

Pareciera como si el caso de uso Cambiar información del estudiante fuera una carac¬ 
terística menor del sistema y no se debiera incluir en el diagrama de caso de uso, pero debi¬ 
do a que esta información cambia con frecuencia, la administración tiene un interés sutil en 
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permitir a los estudiantes cambiar su propia información personal. El hecho de que los ad¬ 
ministradores juzguen esto como importante no sólo justifica, sino que exige, el caso de uso 
a ser escrito. 


Ejemplo de caso de uso, de ; 
matriculación del estudiante. 


A los estudiantes no se les permitiría cambiar su promedio de calificaciones, cuotas a 
pagar y otra información. Este caso de uso también incluye el caso de uso Verificar identi¬ 
dad, y en esta situación, significa que el estudiante tiene que introducir una clave de usua¬ 
rio y contraseña antes de acceder al sistema. Ver información del estudiante permite a los 
estudiantes ver su información personal, así como también los cursos y calificaciones. 

Los diagramas de caso de uso son un buen punto de partida, pero se necesita una des¬ 
cripción más completa de ellos para su documentación. Un caso de uso completo incluirá 
un diagrama de caso de uso y una serie de descripciones explicadas en la siguiente sección. 


DESARROLLO DE ESCENARIOS DE CASO DE USO 


Cada caso de uso tiene una descripción. Nos referiremos a la descripción como un escenario 
de caso de uso. Como se mencionó, el caso de uso principal representa el flujo estándar de 
eventos en el sistema y las rutas alternativas describen las variaciones para el comportamien¬ 
to. Los escenarios de caso de uso podrían describir lo que pasa si un artículo comprado está 
agotado o si una compañía de tarjeta de crédito rechaza la compra solicitada de un cliente. 
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¿FIGURA 18.9 : UiK;'- ' 

Un escenario de caso de uso 
se divide en tres secciones: 
identificación e iniciación, pasos 
desempeñados y condiciones, 
suposiciones y preguntas. 


No hay ningún formato estándar de escenario de caso de uso, de modo que cada orga¬ 
nización se enfrenta con especificar qué estándares se deben incluir. Con frecuencia los ca¬ 
sos de uso se documentan con una plantilla de documento de caso de uso predeterminada 
por la organización, la cual hace los casos de uso fáciles de leer y proporciona información 
estándar para cada caso de uso en el modelo. 

En la figura 18.9 se muestra un ejemplo de escenario de caso de uso. Algunas de las 
áreas incluidas son opcionales y no se podrían usar en todas las organizaciones. Las tres áreas 
principales son: 

1. Identificadores e iniciadores de caso de uso. 

2. Pasos desempeñados. 

3. Condiciones, suposiciones y preguntas. 
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La primera área, identificadores e iniciadores de caso de uso, orientan al lector y contie¬ 
ne el nombre de caso de uso y una ID única; el área de aplicación o sistema que le pertene¬ 
ce a este caso de uso; los actores involucrados en el caso de uso; una breve descripción de lo 
que logra el caso de uso, y la iniciación (activación) del evento, es decir, lo que ocasionó que 
empezara el caso de uso, y el tipo de activación, externo o temporal. Los eventos externos 
son aquellos empezados por un actor. Esto podría ser una persona u otro sistema que pide 
la información, tal como un sistema de reservación de aerolínea que pide la información del 
vuelo de un sistema de la aerolínea. Los eventos temporales son aquellos que se activan o se 
empiezan por tiempo. Los eventos ocurren en un momento específico, tal como enviar un 
correo electrónico sobre ofertas especiales una vez por semana la tarde del domingo, en¬ 
viando las facturas en un día específico o generando estadísticas gubernamentales en una fe¬ 
cha específica cada trimestre. 

La segunda área del caso de uso incluye los pasos desempeñados y la información re¬ 
querida para cada uno de los pasos. Estas declaraciones representan el flujo estándar de 
eventos y los pasos tomados para la realización exitosa del caso de uso. Se desea escribir un 
caso de uso para la ruta principal y después escribir uno por separado para cada una de las 
rutas alternativas, en lugar de usar declaraciones IF... THEN... 

La tercera área del caso de uso incluye las precondiciones, o la condición del sistema 
antes de que se pudiera desempeñar el caso de uso; las poscondiciones, o el estado del siste¬ 
ma después de que el caso de uso se ha terminado; cualesquier suposiciones hechas que pu¬ 
dieran afectar el método del caso de uso; cualesquier asuntos excelentes o preguntas que se 
deben responder antes de la implementación del caso de uso; una declaración opcional de 
prioridad del caso de uso, y una declaración opcional de riesgo involucrada el crear el caso 
de uso. 

Una vez que desarrolle los escenarios de caso de uso, asegúrese de revisar sus resultados 
con los expertos de negocios para verificar y refutar los casos de uso si es necesario. Después 
de finalizar el proceso de verificación y de que todos los expertos de negocios coincidan en 
que los casos de uso son precisos, puede proceder a utilizar las técnicas de diagramación de 
UML para completar el análisis y diseño de sistemas. 


DIAGRAMAS DE ACTIVIDADES 

Los diagramas de actividades muestran las secuencias de actividades de un proceso, inclu¬ 
yendo las actividades secuenciales, las actividades paralelas y las decisiones que se toman. 
Por lo general, un diagrama de actividades se elabora para un caso de uso y podría reflejar 
los diferentes escenarios posibles. 

En la figura 18.10 se ilustran los símbolos de un diagrama de actividades. Un rectángulo 
con esquinas redondeadas representa una actividad, ya sea manual, como firmar un docu¬ 
mento legal; o automatizada, como un método o un programa. 

Una flecha representa un evento. Los eventos representan cosas que ocurren en un 
tiempo y lugar determinados. 

Un diamante representa una decisión (también conocida como rama) o una fusión. Las 
decisiones tienen una flecha que entra en el diamante y varias que salen de él. Se podría in¬ 
cluir una condición que muestre los valores que puede tomar dicha condición. Las fusiones 
muestran varios eventos que se combinan para formar otro evento. 

Un rectángulo largo y plano representa una barra de sincronización. Esta barra se utili¬ 
za para representar actividades paralelas, y podría representar un evento entrando a ella y 
varios eventos saliendo de la misma, lo que se conoce como bifurcación. Una sincronización 
en la cual varios eventos se fusionan en uno solo se conoce como unión. 

Hay dos símbolos que muestran el inicio y el final del diagrama. El estado inicial se 
muestra como un círculo sólido. El estado final se muestra como un círculo negro rodeado 
por un círculo blanco. 

Los rectángulos que rodean otros símbolos llamados carriles (swimlanes) indican un 
particionamiento y se utilizan para mostrar cuáles actividades se realizan en qué platafor¬ 
ma, como un navegador, un servidor o un mainframe; o para mostrar actividades realizadas 
por diferentes grupos de usuarios. Los carriles son zonas que pueden describir la lógica y la 
responsabilidad de una clase. 
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Usted puede ver un ejemplo de carriles en la figura 18.11, la cual ilustra un diagrama 
de actividades para el caso de uso Cambiar Información del Estudiante. Empieza con el es¬ 
tudiante que inicia sesión en el sistema completando un formulario Web y haciendo clic en 
el botón Enviar. El formulario se transmite al servidor Web, que a su vez pasa los datos al 
mainframe. Este accede a la base de datos ESTUDIANTES y manda al servidor Web un 
mensaje "No se encontró" o los datos seleccionados sobre el estudiante. 

El diamante debajo del estado Obtener Registro del Estudiante indica esta decisión. Si 
no se localiza el registro del estudiante, el servidor Web despliega un mensaje de error en la 
página Web. Si se localiza el registro, el servidor Web genera una nueva página Web con los 
datos actuales del estudiante en un formulario Web. El estudiante podría cancelar el cambio 
desde los estados Sistema de Inicio de Sesión o Introducir Cambios, y la actividad se detiene. 

Si el estudiante realiza cambios en el formulario Web y hace clic en el botón Enviar, los 
datos modificados se transmiten al servidor y comienza a ejecutarse un programa que valida 
los datos. Si hay errores, se envía un mensaje de error a la página Web. Si los datos son váli¬ 
dos, el registro del estudiante se actualiza y se escribe un Registro Periódico de Cambios del 
Estudiante. Después de una actualización válida, se envía una página Web de confirmación 
al navegador y finaliza la actividad. 


CREACIÓN DE DIAGRAMAS DE ACTIVIDADES 

Los diagramas de actividades se crean preguntando qué pasa en primer lugar, qué pasa en 
segundo lugar, y así sucesivamente. Usted debe determinar si las actividades se realizan en se¬ 
cuencia o en paralelo. Si se han creado diagramas de flujo de datos físicos (como se describió 
en el capítulo 7], se podrían examinar para determinar la secuencia de actividades. Busque 
lugares donde se tomen decisiones, y pregunte qué ocurre con los resultados de cada una de 
las decisiones. Los diagramas de actividades se podrían crear examinando todos los escena¬ 
rios para un caso de uso. 
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Cada ruta a través de las diversas decisiones incluidas en el caso de uso es un escenario 
diferente. En la ruta principal estaría el Sistema de Inicio de Sesión, Recibir Formulario 
Web, Obtener Registro del Estudiante, Desplegar Datos Actuales del Estudiante, Introdu¬ 
cir Cambios, Validar Cambios, Actualizar Registro del Estudiante, Crear Registro Periódi¬ 
co de Cambios del Estudiante y Desplegar Confirmación. 

Éste no es el único escenario posible de este caso de uso. Podría ocurrir otros. Una po¬ 
sibilidad podría ser el Sistema de Inicio de Sesión, Recibir Formulario Web, Obtener Re¬ 
gistro del Estudiante y Desplegar Mensaje de Error. Otro escenario podría ser el Sistema 
de Inicio de Sesión, Recibir Formulario Web, Obtener Registro del Estudiante, Desplegar 
Datos Actuales del Estudiante, Introducir Cambios, Validar Cambios y Desplegar Mensaje 
de Error. 

Los carriles son útiles para mostrar cómo deben transmitirse o convertirse los datos, co¬ 
mo en el caso de la Web al servidor o del servidor al mainframe. Por ejemplo, el diagrama de 
actividades Cambiar Registro del Estudiante tiene tres carriles. 
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la de mensajes y la decisión se evaluara en el servidor, éste tendría que llamar al mainframe 
otra vez para obtener los datos válidos. Esto retrasaría la respuesta a la persona que espera 
en el navegador. 

Los carriles también ayudan a dividir las tareas en un equipo. Se necesitarían diseñadores 
Web para las páginas Web desplegadas en el navegador del cliente. Otros miembros trabaja¬ 
rían con lenguajes de programación, como Java, PERL o .NET, en el servidor. Los programa- 
dores de CICS escribirían programas para mainframe que trabajarían con la cola de mensajes. 
El analista debe garantizar que los datos requeridos por los diversos miembros del equipo 
estén disponibles y correctamente definidos. En ocasiones los datos en la cola de mensajes 
son un documento de XML. Si se trabaja con una organización externa, los datos también 
podrían ser un documento de XML. 

El diagrama de actividades proporciona un mapa de un caso de uso, y permite al analista 
experimentar con la transferencia de partes del diseño a plataformas diferentes y plantearse 
la pregunta "¿qué pasaría si?" para una variedad de decisiones. El uso de símbolos únicos y 
carriles favorece que las personas prefieran este diagrama para comunicarse con otros. 


DIAGRAMAS DE SECUENCIAS Y DE COLABORACIÓN 

Un diagrama de interacción puede ser un diagrama de secuencias o uno de colaboración, 
que muestran esencialmente la misma información. Estos diagramas, junto con los diagra¬ 
mas de clases, se utilizan en la realización de un caso de uso. 


DIAGRAMAS DE SECUENCIAS 

Los diagramas de secuencias pueden ilustrar una sucesión de interacciones entre clases o 
instancias de objetos en un periodo determinado. Los diagramas de secuencias se utilizan 
con frecuencia para representar el proceso descrito en los escenarios de caso de uso. En la 
práctica, los diagramas de secuencias se derivan del análisis de casos de uso y se emplean en 
el diseño de sistemas para generar las interacciones, relaciones y métodos de los objetos del 
sistema. Los diagramas de secuencias se utilizan para mostrar el patrón general de las activi¬ 
dades o interacciones en un caso de uso. Cada escenario de caso de uso podría crear un dia¬ 
grama de secuencias, aunque no siempre se crean diagramas de este tipo para los escenarios 
menores. 

En la figura 18.12 se muestran los símbolos que se utilizan en diagramas de secuencias. 
Los actores y las clases o instancias de los objetos se muestran en recuadros en la parte su¬ 
perior del diagrama. El objeto del extremo izquierdo es el objeto inicial y podría ser una 
persona [para la cual se emplea símbolo de actor de caso de uso], una ventana, un cuadro de 
diálogo u otra interfaz de usuario. Algunas de las interacciones sólo son físicas, como firmar 
un contrato. Los rectángulos de la parte superior usan indicadores en el nombre para deno¬ 
tar si el rectángulo representa un objeto,-una clase, o una clase y un objeto. 

nombreDelObjeto: Un nombre seguido de dos puntos representa un objeto. 

xlase Dos puntos seguidos de un nombre representan una clase. 

nombreDelObjetoxlase Un nombre, seguido de dos puntos y otro nombre, repre¬ 
senta un objeto de una clase. 

Una línea vertical representa la trayectoria de la vida de la clase o del objeto, que co¬ 
mienza cuando se crea y finaliza cuando se destruye. Una X en el fondo de la trayectoria de 
la vida indica cuándo se destruye el objeto. Una barra lateral o rectángulo vertical en la 
trayectoria de la vida muestran el enfoque de control cuando el objeto se encuentra reali¬ 
zando algo. 

Las flechas horizontales muestran mensajes o signos que se envían entre las clases. Los 
mensajes pertenecen a la clase receptora. Hay algunas variaciones en las flechas de mensaje. 
Las puntas de flecha sólidas representan llamadas síncronas, que son las más comunes. Es¬ 
tas se usan cuando la clase emisora espera una respuesta de la clase receptora, y el control 
se devuelve a la clase emisora cuando la clase que recibe el mensaje termina su ejecución. 
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Las flechas con media punta (o abiertas) representan llamadas asincronas, es decir, llama¬ 
das que se envían sin esperar a que sean devueltas a la clase que las emite. Un ejemplo podría 
ser el de usar un menú para ejecutar un programa. Un retorno se muestra como una flecha, 
a veces con una línea punteada. Los mensajes se etiquetan mediante alguno de los forma¬ 
tos siguientes: 

• El nombre del mensaje seguido por paréntesis vacíos: 

nombreDelMensaje( ). 

0 El nombre del mensaje seguido por parámetros entre paréntesis: 
nombreDelMensaje(parámetrol, parámetro2.„). 

8 El nombre del mensaje seguido por el tipo del parámetro, nombre del parámetro 
y cualquier valor predeterminado para el parámetro entre paréntesis: 
nombreDelMensaje(tipoDelParámetro:nombreDelParámetro(valorPredetemiinado). 

Los tipos de parámetro indican el tipo de los datos, como numérico, alfanumérico o 
de tipo de fecha. 

• El mensaje podría ser un estereotipo, como - A Créate», lo cual indica que se crea 
un nuevo objeto como resultado del mensaje. 

En el diagrama de secuencias el tiempo se despliega de arriba abajo; la primera interac¬ 
ción se representa en la parte superior del diagrama, y la última, en la parte inferior. Las fle¬ 
chas de interacción comienzan en la barra del actor o del objeto que inicia la interacción, y 
terminan apuntando hacia la barra del actor o el objeto que recibe la solicitud de interac¬ 
ción. El actor, la clase o el objeto iniciales se muestran a la izquierda. Este podría ser el 
actor que inicia la actividad o podría ser una clase que represente la interfaz de usuario. 

La figura 18.13 es un ejemplo simplificado de un diagrama de secuencias para un caso 
de uso que admite a un estudiante a una universidad. En la parte izquierda se encuentra la 
clase interfazDeUsuarioDeNuevoEstudiante que se utiliza para obtener información del 
estudiante. El mensaje inicializar( ) se envía a la clase Estudiante, que crea un nuevo regis¬ 
tro del estudiante y devuelve el número de este último. Para simplificar el diagrama, se han 
omitido los parámetros que se envían a la clase Estudiante, pero entre éstos estarían el 
nombre del estudiante, la dirección, etc. La siguiente actividad es enviar un mensaje selec- 
cionarDormitorio a la clase Dormitorio. Este mensaje incluiría información relativa a la 
selección del dormitorio, como un dormitorio del área de salud u otros requerimientos del 
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estudiante. La clase Dormitorio devuelve el nombre del dormitorio y el número de habita¬ 
ción. La tercera actividad es enviar un mensaje seleccionarPrograma a la clase Programa, 
incluyendo el nombré del programa y otra información del curso de estudio. El nombre del 
asesor del programa se devuelve a la clase interfazDeUsuarioDeNuevoEstudiante. Un men¬ 
saje estudianteCompleto se envía a la clase Estudiante con el dormitorio, el nombre del ase¬ 
sor e información adicional. 

Los diagramas de secuencias pueden usarse para traducir el escenario de caso de uso a 
una herramienta visual para el análisis de sistemas. El diagrama de secuencias inicial utilizado 
en el análisis de sistemas muestra los actores y clases del sistema y las interacciones que ocu¬ 
rren entre ellos para un proceso específico. Usted puede usar esta versión del diagrama de 
secuencias para verificar procesos con los expertos del área de negocios que le han ayudado 
a desarrollar los requerimientos del sistema. Un diagrama de secuencias pone énfasis en la 
clasificación de los mensajes según el tiempo [secuencia). 

Los diagramas de secuencias se refinan durante la fase de diseño del sistema para de¬ 
rivar los métodos e interacciones entre las clases. Los mensajes de una clase se utilizan 
para identificar las relaciones de la clase. Los actores de los primeros diagramas de se¬ 
cuencias se traducen en interfaces y las interacciones se traducen en métodos de clase. 
Los métodos de clase que se utilizan para crear instancias de otras clases y para realizar 
otras funciones internas del sistema surgen en el diseño del sistema al utilizar diagramas 
de secuencias. 


DIAGRAMAS DE COLABORACION 

Las colaboraciones describen las interacciones de dos o más cosas en el sistema, las cuales 
desempeñan en conjunto un comportamiento superior al que puede realizar cualquiera de 
las cosas por sí sola. Por ejemplo, un automóvil puede dividirse en miles de partes indivi¬ 
duales. Las partes se conjuntan para formar los principales subsistemas del vehículo: el mo¬ 
tor, la transmisión, el sistema de frenos, etc. Las partes individuales del automóvil se pueden 
considerar como clases, porque tienen distintos atributos y funciones. Las partes individua¬ 
les del motor forman una colaboración, porque "colaboran" entre sí para hacer funcionar el 
motor cuando el conductor pisa el acelerador. 
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Diagrama de colaboración para 
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Los diagramas de colaboración 
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énfasis en la organización de 
los objetos en lugar de en la 
clasificación según el tiempo. 
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Los diagramas de colaboración muestran la misma información que un diagrama de se¬ 
cuencias, pero su lectura podría ser más difícil. Para denotar la clasificación en el tiempo, us¬ 
ted debe indicar un número de secuencia y describir el mensaje. 

Un diagrama de colaboración pone énfasis en la organización de los objetos, en tanto que 
un diagrama de secuencias lo pone en la clasificación de los mensajes según el tiempo. Un 
diagrama de colaboración mostrará una ruta para indicar cómo se enlaza un objeto con otro. 

Algunas herramientas CASE, como Rose de IBM, convierten automáticamente un dia¬ 
grama de secuencias en un diagrama de colaboración o viceversa, con sólo un clic en un bo¬ 
tón. En la figura 18.14 se ilustra un diagrama de colaboración para el ejemplo de admisión 
del estudiante. Cada rectángulo representa un objeto o una clase. Las líneas conectoras 
muestran las clases que necesitan colaborar o trabajar entre sí. Los mensajes que se envían 
de una clase a otra se ilustran junto a las líneas conectoras. Los mensajes se numeran para 
mostrar la secuencia de tiempo. Los valores devueltos también se pueden incluir y numerar 
para indicar en qué momento de la secuencia de tiempo se devuelven. 


DIAGRAMAS DE CLASE 

Las metodologías orientadas a objetos se enfocan en descubrir clases, atributos, métodos y 
relaciones entre las clases. Puesto que la programación se realiza al nivel de la clase, la defi¬ 
nición de clases es una de las tareas más importantes del análisis orientado a objetos. Los 
diagramas de clases muestran las características estáticas del sistema y no representan nin¬ 
gún procesamiento en particular. Un diagrama de clases también muestra la naturaleza de 
las relaciones entre las clases. 

Las clases se representan mediante rectángulos en un diagrama de clases. En el formato 
más simple, el rectángulo podría incluir sólo el nombre de la clase, pero también podría in¬ 
cluir los atributos y métodos. Los atributos son lo que la clase sabe sobre las características 
de los objetos, y los métodos (también conocidos como operaciones] constituyen lo que la 
clase sabe sobre cómo hacer las cosas. Los métodos son secciones pequeñas de código que 
trabajan con los atributos. 

La figura 18.15 ilustra un diagrama de clases para ofrecimientos de cursos. Observe que 
el nombre se centra en la parte superior de la clase, por lo general en negritas. El área direc¬ 
tamente debajo del nombre muestra los atributos, y los métodos se encuentran en la parte 
inferior. El diagrama de clases denota los requerimientos de almacenamiento de datos así 
como los de procesamiento. Más adelante explicaremos el significado de los símbolos de 
diamante que se aprecian en esta figura. 

Por lo general, los atributos (o propiedades] se designan como privados, o disponibles 
sólo para el objeto. Esto se representa en un diagrama de clases mediante un signo de resta 
antes del nombre del atributo. Los atributos también pueden designarse como protegidos, 
lo cual se indica con el símbolo de número (#]. Estos atributos están ocultos para todas las 
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clases, excepto para las subclases inmediatas. En circunstancias poco comunes, un atributo 
es público, lo cual significa que es visible para otros objetos fuera de su clase. Al hacer pri¬ 
vados a los atributos sólo están disponibles para los objetos externos a través de los métodos 
de la clase, una técnica llamada encapsulamiento, u ocultamiento de información. 

Un diagrama de clases podría mostrar simplemente el nombre de la clase; o el nombre 
de la clase y los atributos; o el nombre de la clase, los atributos y los métodos. Mostrar sólo 
el nombre de la clase es útil cuando el diagrama es muy complejo e incluye muchas clases. 
Si el diagrama es más sencillo, se podrían incluir atributos y métodos. Cuando se incluyen 
atributos, hay tres maneras de mostrar su información correspondiente. La más simple es in¬ 
cluir sólo el nombre del atributo, que toma la menor cantidad de espacio. 

El tipo de datos (por ejemplo, numérico, alfanumérico, entero o fecha} podría incluirse 
en el diagrama de clases. Las descripciones más completas podrían incluir un signo de igual 
(=-) después del tipo de datos, seguido por el valor inicial del atributo. La figura 18.16 ilus¬ 
tra los atributos de la clase. 

Si el atributo debe adoptar algún valor de entre un número finito, como un tipo de es¬ 
tudiante con valores de C para tiempo completo, M para medio tiempo y N para no inscrito, 
éstos pueden incluirse entre llaves, separados por comas: tipoDeEstudiante:char{C,M,N}. 

El ocultamiento de información significa que los métodos de los objetos deben estar 
disponibles para otras clases, así que con frecuencia los métodos son públicos, lo cual quiere 
decir que podrían ser invocados desde otras clases. En un diagrama de clases, los mensajes 
públicos (y cualquier atributo público) se muestran con un signo de suma (+) antes del 
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nombre. Los métodos también tienen paréntesis a continuación del nombre, lo cual indica 
que se podrían pasar datos como parámetros junto con el mensaje. Los parámetros del men¬ 
saje, así como el tipo de datos, se podrían incluir en el diagrama de clases. 

Hay dos tipos de métodos: estándar y personalizado. Los métodos estándar son cosas 
básicas que todas las clases de objetos saben hacer, como crear una nueva instancia del ob¬ 
jeto. Los métodos personalizados se diseñan para una clase específica. 


SOBRECARGA DE MÉTODOS 

La sobrecarga de métodos se refiere a incluir el mismo método [u operación) varias veces 
en una clase. La firma del método abarca el nombre del método y los parámetros que con¬ 
tiene. El mismo método podría definirse más de una vez en una clase determinada, con la 
condición de que los parámetros enviados como parte del mensaje sean diferentes; es decir, 
el mensaje debe tener una firma diferente. Podría tener un número diferente de parámetros, 
o éstos podrían ser de un tipo diferente, como number (numérico) en un método y string 
(alfanumérico) en otro método. Un ejemplo de sobrecarga de métodos podría encontrarse 
en el uso de un signo de suma en muchos lenguajes de programación. Si los atributos a am¬ 
bos lados del signo de suma son números, los dos números se suman. Si los atributos son ca¬ 
denas de caracteres, las cadenas se concatenan para formar una cadena larga. 

En un ejemplo de depósito bancario, una ficha de depósito podría contener simple¬ 
mente la cantidad del depósito, en cuyo caso el banco depositaría la cantidad completa, o 
podría contener la cantidad del depósito y la cantidad de dinero en efectivo que se tendría 
que devolver. Ambas situaciones usarían un método de cheque de depósito, pero los pará¬ 
metros (una situación también solicitaría la cantidad de dinero en efectivo que se tendía 
que devolver) serían diferentes. 


TIPOS DE CLASES 

Las clases entran en cuatro categorías: de entidad, de interfaz, abstractas y de control. Estas 
categorías se explican a continuación. 

Clases de entidad Las clases de entidad representan elementos de la vida real, como gente, 
cosas, etc. Las clases de entidad son las entidades representadas en un diagrama entidad-re¬ 
lación. Las herramientas CASE como Visible Analyst le permitirán crear una clase de enti¬ 
dad UML a partir de una entidad de un diagrama de E-R. 

El analista necesita determinar qué atributos incluir en las clases. Cada objeto tiene 
muchos atributos, pero la clase debe incluir sólo aquellos que utiliza la organización. Por 
ejemplo, al crear una clase de entidad para un estudiante de una universidad, usted necesi¬ 
taría conocer qué atributos identifican al estudiante, como la dirección de la casa y del cam¬ 
pus, así como el promedio de calificaciones, créditos totales, etc. Si usted estuviera dando 
seguimiento al mismo estudiante para una tienda de ropa en línea, usted tendría que cono¬ 
cer información básica que lo identifique, así como otros atributos descriptivos como medi¬ 
das o preferencias de color. 

Clases de límite, o de interfaz Las clases de límite, o interfaz, ofrecen a los usuarios un 
medio para trabajar con el sistema. Existen dos amplias categorías de clases de interfaz: hu¬ 
mana y de sistema. 

Una interfaz humana puede ser una pantalla, una ventana, un formulario Web, un cua¬ 
dro de diálogo, un menú, un cuadro de lista u otro control de despliegue. También puede ser 
un teléfono de tonos, un código de barras o algún otro medio que permita a los usuarios in¬ 
teractuar con el sistema. Deben crearse prototipos de las interfaces humanas (como se des¬ 
cribió en el capítulo 6), y a menudo se usa un storyboard (una ilustración del argumento o 
secuencia escena por escena) para modelar la secuencia de interacciones. 

Las interfaces del sistema implican el envío o recepción de datos de otros sistemas. Es¬ 
to podría incluir a las bases de datos de la organización. Si los datos se envían a una organi- 
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zación externa, a menudo se encuentran en forma de archivos de XML u otras interfaces 
bien publicadas con mensajes y protocolos definidos de manera clara. Las interfaces exter¬ 
nas son las menos estables, porque con frecuencia hay poco o ningún control sobre un socio 
externo que podría alterar el formato del mensaje o los datos. 

XML ayuda a proporcionar estandarización, porque un socio externo podría agregar 
nuevos elementos al documento XML, pero una corporación que transforme los datos a un 
formato que pudiera utilizarse para incorporarlos a una base de datos interna podría elegir 
simplemente ignorar los elementos adicionales sin ningún problema. 

Los atributos de estas clases son los que se encuentran en una pantalla o un infor¬ 
me. Los métodos son los que se requieren para trabajar con la pantalla o para producir el 
informe. 

Clases abstractas Son las clases que no es posible instanciar directamente. Las clases 
abstractas están vinculadas a clases concretas en una relación generalización/especiali- 
zación [gen/spec]. Por lo general, el nombre de una clase abstracta se denota en letras 
cursivas. 

Clases de control Las clases de control, o activas, se utilizan para controlar el flujo de acti¬ 
vidades, y funcionan como coordinadoras al implementar clases. Para lograr clases reutiliza- 
bles, un diagrama de clases podría incluir muchas clases pequeñas de control. Con frecuen¬ 
cia, las clases de control se derivan durante el diseño del sistema. 

A menudo una nueva clase de control se creará sólo con el propósito de hacer reutili- 
zable otra clase. Un ejemplo podría ser el proceso de inicio de sesión. Podría existir una clase 
de control para la interfaz de usuario de inicio de sesión, que contenga la lógica para verifi¬ 
car la contraseña y la ID de usuario. El problema que surge es que la clase de control de 
inicio de sesión se diseña para una pantalla de inicio de sesión específica. Al crear una clase 
de control que sólo maneje esta pantalla de inicio de sesión, los datos se pueden pasar a una 
clase de control de validación más general que compruebe las contraseñas e IDs de usuario 
provenientes de muchas otras clases de control que reciban mensajes de interfaces de usua¬ 
rio específicas. Esto incrementa la reusabilidad y aísla los métodos de verificación de inicio 
de sesión de los métodos que manejan la interfaz de usuario. 


UN EJEMPLO DE CLASE PARA LA WEB 

También pueden utilizarse símbolos especiales para representar las clases de entidad, límite 
(o interfaz) y de control. Estos se denominan estereotipos, una extensión de UML, que son 
símbolos especiales que podrían utilizarse durante el análisis pero que se emplean a menu¬ 
do al realizar el diseño orientado a objetos. Estos símbolos dan libertad al analista para ex¬ 
perimentar con el diseño y optimizar la reusabilidad. 

Los diferentes tipos de clases a menudo se utilizan al trabajar en la fase de diseño de sis¬ 
temas. La figura 18.17 constituye un ejemplo para ilustrar un diagrama de secuencias que 
representa a un estudiante que ve su información personal y del curso. En el diagrama, ¡Ver 
Interfaz de Usuario del Estudiante es un ejemplo de clase de interfaz; ¡Estudiante, ¡Sección 
y ¡Curso son ejemplos de clases de entidad, y :Ver Controlador de Interfaz del Estudiante y 
¡Calcular Promedio de Calificaciones son clases de control. 

El estudiante se muestra a la izquierda como un actor y proporciona un inicioDeSe- 
sionDeUsuario a la clase :Ver Interfaz de Usuario del Estudiante. Éste es un formulario 
Web que obtiene la contraseña e ID de usuario del estudiante. Cuando el estudiante hace 
clic en el botón Enviar, el formulario Web se pasa a una clase :Ver Controlador de Interfaz 
del Estudiante. Esta clase es responsable de la coordinación del envío de mensajes y de re¬ 
cibir la información devuelta por todas las demás clases. 

Las clase :Ver Controlador de Interfaz del Estudiante envía un mensaje obtenerEstu- 
diantef) a la clase ¡Estudiante, que lee una tabla de la base de datos y procede a devolver 
los datosDelEstudiante. 

La paginaWebDelEstudiante es devuelta a la clase ¡Ver Interfaz de Usuario del Estu¬ 
diante, que se encarga de desplegar la información en el navegador Web. En la parte inferior 
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Diagrama de secuencias para 
utilizar dos páginas Web: una 


para información del estudiante 
y otra para la información de 
cursos. 


de la página se encuentra un botonSiguieníe, en el cual el estudiante hace clic para ver 
los cursos. Cuando el usuario hace clic en este botón, envía un formulario Web a la clase 
:Ver Controlador de Interfaz del Estudiante. Este formulario contiene el numeroDelEstu- 
diantef), enviado junto con paginaWebDelEstudiante, y se usa para enviar un mensaje a la 
clase :Seccion para obtener la calificación de la sección; es decir, la calificación que obtuvo 
el estudiante en ese grupo o sección del curso seleccionado. Si el numeroDelEstudiante() 
no se envía automáticamente, significaría que el estudiante tendría que introducir su nume- 
roDel EstudianteQ de nueva cuenta, lo cual denotaría una pobre interfaz de usuario por¬ 
que implicaría tecleo redundante. Observe que la clase ¡Estudiante no interviene, y que el 
enfoque del control (la barra vertical que se conecta a la clase ¡Estudiante) finaliza antes de 
que comience el segundo conjunto de actividades (las flechas horizontales que apuntan ha- 
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cia la derecha). La clase ¡Ver Controlador de Interfaz del Estudiante envía un mensaje ob¬ 
tener Secciont) a la clase ¡Sección que devuelve una calificacionDeSeccion. La clase ¡Sec¬ 
ción también envía un mensaje calcularPC() a la clase ¡Calcular Promedio de Calificacio¬ 
nes, que devuelve un mensaje a la clase ¡Curso. Esta clase devuelve los créditos, que 
permiten a la clase ¡Calcular Promedio de Calificaciones determinar el promedio de las ca¬ 
lificaciones y devolverlo a la clase ¡Ver Controlador de Interfaz del Estudiante. 

La clase ¡Ver Controlador de Interfaz del Estudiante repetiría el envío de mensajes a 
la clase ¡Sección hasta que se incluyan todas las secciones del estudiante. En este momen¬ 
to, la clase ¡Ver Controlador de Interfaz del Estudiante enviaría la paginaWebDelCurso 
a la clase ¡Ver Interfaz de Usuario del Estudiante, que desplegaría la información en el 
navegador. 

El uso de las clases de interfaz de usuario, de control y de entidad también permite 
al analista explorar y experimentar con el diseño. El diseño antes mencionado desplegaría 
toda la información personal del estudiante en una página y la información del curso en 
una segunda página. El analista podría modificar el diseño para que la información per¬ 
sonal del estudiante y la información del curso aparecieran en una sola página Web. Es¬ 
tos dos escenarios posibles tendrían que revisarse con los usuarios para determinar la 
mejor alternativa. 

Una de las dificultades para el analista es determinar cómo incluir el numeroDelEstu- 
diante después de que se haga clic en el botón Siguiente, porque la clase ¡Estudiante ya no 
está disponible. Existen tres maneras para guardar y retransmitir datos de una página Web: 

1. Incluir la información en el URL que se despliega en el área de dirección del navegador. 

En este caso, la línea de localización podría ser parecida a la siguiente: 

http://www.cpu.edu/student/studentinq.html7studentNumbei-12345 

Todo lo que se encuentra después del signo de interrogación son datos que podrían 
ser utilizados por los métodos de clase. Este medio de guardar datos es fácil de imple- 
mentar y con frecuencia lo utilizan los motores de búsqueda. 

Existen varias desventajas al usar este método, y el analista debe emplearlo con la 
debida cautela. La primera preocupación es la privacidad —cualquiera puede leer la di¬ 
rección Web—. Si la aplicación involucra información médica, números de tarjeta de 
crédito, etc., ésta no es una buena opción. La mayoría de los navegadores también des¬ 
pliegan datos de las direcciones Web anteriores en sesiones subsecuentes si el usuario in¬ 
troduce los primeros caracteres, y de esta manera la información podría comprometerse 
al propiciar el robo de identidad. Una segunda desventaja es que por lo general los datos 
se pierden cuando el usuario cierra el navegador. 

2. Guardar la información en una cookie, un pequeño archivo que se almacena en la compu¬ 
tadora (el navegador) del cliente. Las cookies constituyen la única manera de guardar 
datos persistentes, que permanecen aún después de finalizar la sesión actual del nave¬ 
gador. Esto permite a la página Web desplegar un mensaje similar a "Bienvenido, Mi¬ 
guel. Si usted no es Miguel, haga clic aquí". Por lo general, las cookies guardan números 
de cuenta importantes, pero no números de tarjeta de crédito ni otra información pri¬ 
vada. Las cookies se limitan a 20 por dominio (como wwrw.cpu.edu) y cada cookie debe 
tener 4,000 caracteres o menos. 

3. Utilizar campos de formulario Web ocultos. Estos campos normalmente contienen da¬ 
tos enviados por el servidor, son invisibles y no ocúpan espacio en la página Web. En el 
ejemplo de la vista de información del estudiante, la clase ¡Ver Controlador de Interfaz 
del Estudiante agregó un campo oculto al formulario paginaWebDelEstudiante con el 
numeroDelEstudiante y el botonSiguiente. Cuando el estudiante hace clic en el boton- 
Siguiente, el numeroDelEstudiante se envía al servidor y de esta manera la clase ¡Ver 
Controlador de Interfaz del Estudiante sabe de qué estudiante debe obtener la infor¬ 
mación de curso y calificaciones. Los datos de los formularios ocultos no se guardan de 
una sesión del navegador a otra, por lo que se conserva la privacidad. 

Los símbolos de clase también se podrían usar en diagramas de clases y de colabora¬ 
ción. La figura 18.18 ilustra el diagrama de clases para un estudiante que ve información 
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personal y del curso en páginas Web. Cada clase tiene atributos y métodos (los cuales no se 
muestran en diagramas que usan esta notación). 

Si la clase es del tipo de interfaz de usuario, los atributos son los controles (o campos] 
de la pantalla o el formulario. Los métodos podrían ser aquellos que interactúan con la pan¬ 
talla, como enviar o restablecer. También podrían ser JavaScript para una página Web, por¬ 
que el código trabaja directamente con la página Web. 

Si la clase es de control, los atributos podrían ser aquellos necesarios para implementar 
la clase, como las variables que sólo se utilicen en ella. Los métodos podrían ser aquellos uti¬ 
lizados para realizar cálculos, tomar decisiones y enviar mensajes a otras clases. 

Si la clase es de entidad, los atributos representan aquellos guardados para la entidad y 
los métodos que trabajan directamente con la entidad, como crear una nueva instancia, mo¬ 
dificar, eliminar, obtener o imprimir. 

Los sitios Web podrían usar una combinación de muchas clases diferentes para satisfa¬ 
cer los objetivos del usuario. Por ejemplo, un sitio Web podría usar JavaScript para prevalidar 
los datos, y pasarlos a continuación a las clases de control del servidor, que realizan la vali¬ 
dación completa junto con la obtención de datos. Las clases de control del servidor, a su vez, 
podrían devolver JavaScript a la página Web para realizar algún formato. No es raro que una 
aplicación Web incluya muchas clases, algunas de ellas con sólo una línea de código en un 
método, para conseguir el objetivo de la reusabilidad. 


RELACIONES 

Las relaciones son conexiones entre las clases, similares a aquellas que se encuentran en un 
diagrama de entidad-relación. Estas relaciones se muestran como líneas que conectan las 
clases en un diagrama de clases. Hay dos categorías de relaciones: asociaciones y relaciones 
todo/parte. 

Asociaciones El tipo más simple de relación es una asociación, o una conexión estructural 
entre clases u objetos. Las asociaciones se muestran como una línea simple en un diagrama 
de clases. Ixts puntos finales de la línea se etiquetan con un símbolo que indica la multipli¬ 
cidad, que es lo mismo que la cardinalidad en un diagrama de entidad-relación. Un cero re- 
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-numeroDelEstudiante 
-creditosTermmados ;¡ ^ 

-promedioDeCaliticaciones 
-departamento: 
-especializacion I : ■ • : 

. tinca ¡zar;: I 
•i-verEstudiante() 
+cambiarEstudiante() 
+estudianteDeLicenciatura() 


-nombreDelDormitorio 
-númeroDeHabitacion 
-tamañoDeHabitacion 
-sexoDelOcupánte ' : 
-numeroDeHabitacionesVacantes 
i agregar-lao tac onc ; / 
+cambiarHabitacion() : 
+buscarHabitacion() 
+cambiarHabitacionesVacantes 


-numeroDelEstudiante 
crocitos lo-minados 
-promedioDeCalificaciones 
departamento ; 
-especializacion .. 

imicializaro — 
+verEstudiante() '; 
-rcambiarEstud ante () 
+estudianteDeLicenciatura() 


participa en 


Actividad voluntaria 

-numeroDeActividad 
-descripcionDeActividad 
-orgamzacionDeActividad 
-fechaDeActividád 
^numeroDelEstudiante. . 
.+agregarActiV|dad() 
+cambiarActividad() 
+buscarActivjdad() • 
+agregarVoluntario() 


presenta ninguno, un uno representa uno y sólo uno, y un asterisco representa muchos. La 
notación 0..1 representa de cero a uno, y la notación 1..* representa de uno a muchos. Las 
asociaciones se ilustran en la figura 18.19. 

Los diagramas de clases no restringen el límite inferior de una asociación. Por ejemplo, 
una asociación podría ser 5..*, lo cual indicaría que debe estar presente un mínimo de cin¬ 
co. Lo mismo se aplica a los límites superiores. Por ejemplo, el número de cursos en que se 
matricule actualmente un estudiante podría ser L. 10, lo cual representaría de uno a 10 cur¬ 
sos. También puede incluir un rango de valores separados por comas, como 2, 3, 4. En el 
modelo de UML, las asociaciones por lo general se etiquetan con un nombre descriptivo. 

Las clases de asociación son aquellas que se usan para dividir una asociación muchos a 
muchos entre clases. Éstas son similares a las entidades asociativas en un diagrama entidad- 
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Ejemplo de una clase asociativa 
en la cual una sección particular 
define la relación entre un 
estudiante y un curso. 



relación. Estudiante y Curso tienen una relación muchos a muchos, que se resuelve agre¬ 
gando una clase de asociación llamada Sección entre las clases Estudiante y Curso. La figu¬ 
ra 18.20 ilustra una clase de asociación llamada Sección, mostrada con una línea punteada 
conectada a la línea de la relación muchos a muchos. 

Un objeto de una clase podría tener una relación con otros objetos de la misma clase, lo 
que se conoce como asociación reflexiva. Un ejemplo sería una tarea que tiene una tarea 
precedente, o un empleado que supervisa a otro empleado. Esto se muestra como una línea 
de asociación que conecta la clase a sí misma, con etiquetas que indican el nombre del pa¬ 
pel, como tarea y tarea precedente. 

Relaciones todo/parte Estas relaciones surgen cuando una clase representa al objeto total 
y otras clases representan partes del mismo. El todo actúa como contenedor de las partes. 
Estas relaciones se muestran en un diagrama de clases mediante una línea con un diamante 
en un extremo. El diamante se conecta al objeto total. Las relaciones todo/parte [así como 
la agregación, que se explica debajo) se muestran en la figura 18.21. 

Una relación todo/parte podría ser un objeto entidad que tiene partes distintas, como 
un sistema de cómputo que incluye computadora, copiadora, monitor, etc., o un automóvil 
que tiene motor, sistema de frenos, transmisión, etc. Las relaciones todo/parte también se 
pueden usar para describir una interfaz de usuario, en la cual una pantalla de GUI contiene 
una serie de objetos como listas, cuadros o botones de opción, o tal vez un área de encabe¬ 
zado, cuerpo y pie. Las relaciones todo/parte tienen varias categorías: agregación, colección 
y composición. 


Agregación. A menudo, una agregación se describe como una relación "tiene un". La 
agregación proporciona un medio para mostrar que el objeto total se compone de la suma 
de sus partes (otros objetos). En el ejemplo de matriculación del estudiante, el departamen¬ 
to tiene un curso y el curso es para un departamento. Esta es una relación más débil, porque 
un departamento podría cambiarse o eliminarse y el curso todavía existiría. Un paquete de 
computadora podría no estar disponible, pero las impresoras y otros componentes todavía 
existen. El diamante al final de la línea de la relación no aparece sólido. 


Colección. Una colección consta de un todo y sus miembros. Éste podría ser un distri¬ 
to electoral con votantes o una biblioteca con libros. Los votantes o libros podrían cambiar, 
pero el todo conserva su identidad. Ésta es una asociación débil. 
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_ Estudiante _ 

-numéroDétEstüdiáhte 1 " 
•creclltosTermlnados 
-promeclioDeCalificaciones 
•departamento 
•Gspecializacion 
-especializacionSecundaria : 
+cambiarEstudianté() 
+busoarEstJd¡anteQ ifj 
+estudiantebeLicenciatura() 
+¡mcial¡zar(). 
+complétarÉstudianté() .. 
+verEstud¡ante() ■ 


Organización del Campus 

•numeroDeOrgamzacion 
•nombreDeOrganizacioh 
•t poDcC'gan.zac cr 
•oros cero ■' 

-tesorero " . ■ v 

•secretario ¡r LA j 
•saJdoDéCuenta 
•numeroDeiVIiembros 

+cambigr(¡ 

reamo arFjrcona'os;).' •' 
-rie’vrj : • 


Ejemplo de relaciones todo/parle 
y de agregación.'; 


Actividad para Recaudar 
_ Fondos _ 

-rume.roDeActiyidad • 
•descripción De Actividad 
—tipoDeActividad 
•cantidadlnvertida 
-cantidadRecibida ■ 
-fechaterminaCion. " , 

+cambiarf.), 

+nueVO() ’ii ; :v 
+registrarCantidad( f... 


Composición. La composición, una relación todo/parte en la cual el todo tiene una 
responsabilidad por la parte, es una relación aún más fuerte, y normalmente se muestra con 
un diamante sólido. Las palabras clave para la composición son que una clase "siempre 
contiene" a otra clase. Si el todo se elimina, todas las partes se eliminan. Un ejemplo seria 
una póliza de seguro con cláusulas adicionales. Si la póliza se cancela, las cláusulas adiciona¬ 
les también se cancelan. En una base de datos, se podría establecer integridad referencial 
para eliminar los registros hijos en cascada. En una universidad hay una relación de compo¬ 
sición entre un curso y una tarea así como entre un curso y un examen. Si el curso se elimi¬ 
na, las tareas y exámenes también se eliminan. 


DIAGRAMAS DE GENERAUZACiON/ESPECIAUZACiQN 

Un diagrama de generalización/especialización (gen/esp) entra en la categoría de diagrama 
de clases. En ocasiones es necesario separar las generalizaciones de las instancias específicas. 
Como mencionamos al principio de este capítulo, un oso koala es parte de una clase de 
marsupiales, que a su vez es parte de una clase de animales. A veces necesitamos distinguir 
si un oso koala es un animal o un tipo de animal. Además, un oso koala puede ser un animal 
de peluche. En consecuencia, a menudo requerimos clarificar estas sutilezas. 

Generalización Una generalización describe una relación entre un tipo general de cosa y 
un tipo más específico de cosa. Este tipo de relación se describe a menudo como una rela¬ 
ción "es un". Por ejemplo, un automóvil es un vehículo y un camión es un vehículo. En este 
caso, el vehículo es la cosa general, en tanto que el automóvil y el camión son las cosas más 
específicas. Las relaciones de generalización se utilizan para modelar la herencia de clases y 
la especialización. Una clase general a veces se conoce como superclase, clase base o clase 
madre; una clase especializada se denomina subclase, clase derivada o clase hija. 
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Herencia Varias clases podrían tener los mismos atributos y/o métodos. Cuando esto ocu¬ 
rre, se crea una clase general que contiene los atributos y métodos comunes. La clase espe¬ 
cializada hereda o recibe los atributos y métodos de la clase general. Además, la clase es¬ 
pecializada tiene atributos y métodos que son únicos y sólo están definidos en la clase 
especializada. La creación de clases generalizadas y el hecho de permitir que la clase espe¬ 
cializada herede sus atributos y métodos fomenta la reutilización, porque el código se usa 
muchas veces. También ayuda a dar mantenimiento al código de los programas existentes. 
Esto da al analista la posibilidad de definir atributos y métodos una sola vez y usarlos mu¬ 
chas veces, en cada clase heredada. 

Una de las características especiales del enfoque orientado a objetos es la creación y 
mantenimiento de grandes bibliotecas de clases que están disponibles en diversos lenguajes. 
Así, por ejemplo, un programador que usa Java, ,NET o C# tendrá acceso a una considera¬ 
ble cantidad de clases que ya se han desarrollado. 

Polimorfismo El polimorfismo (que significa muchas formas), o redefinición de métodos 
(que es diferente a la sobrecarga de métodos), es la capacidad de un programa orientado a 
objetos para tener varias versiones del mismo método con el mismo nombre dentro de una 
relación superclase/subclase. La subclase hereda un método de su clase madre pero podría 
agregarle comportamiento o modificarlo. La subclase podría cambiar el tipo de datos, o 
cambiar la forma en que trabaja el método. Por ejemplo, un cliente podría recibir un des¬ 
cuento adicional por volumen, y el método para calcular el total de un pedido se modifica. 
Se dice que el método de la subclase redefine (o sobrepone) al método de la superclase. 

Cuando los atributos o métodos se definen más de una vez, se utiliza el más específico 
(el más bajo en la jerarquía de clases). El programa compilado sube por la cadena de clases 
en busca de los métodos. 

Clases abstractas Las clases abstractas son clases generales y se utilizan cuando se incluye 
gen/esp en el diseño. La clase general se convierte en la clase abstracta. La clase abstracta no 
tiene objetos directos o instancias de clase, y sólo se usa con clases especializadas. Por lo ge¬ 
neral, las clases abstractas tienen atributos y podrían incluir algunos métodos. 

La figura 18.22 es un ejemplo de un diagrama de clases de gen/esp. La flecha apunta 
hacia la clase general, o superclase. A menudo las líneas que conectan dos o más subclases a 
una superclase se unen con una flecha que apunta hacia la superclase, aunque también se 
podrían mostrar como flechas separadas. Observe que el nivel superior es Persona, y repre¬ 
senta a cualquier persona. Los atributos describen cualidades que todas las personas de una 
universidad poseen. Los métodos permiten a la clase cambiar el nombre y la dirección (in¬ 
cluyendo el teléfono y la dirección de correo electrónico). Esta es una clase abstracta, sin 
instancias. 

Estudiante y Empleado son subclases, porque tienen atributos y métodos diferentes. 
Un empleado no tiene un promedio de calificaciones y un estudiante no tiene un sueldo. 
Esta es una versión simple, y no incluye a empleados que sean estudiantes ni a estudiantes 
que trabajen para la universidad. Si se agregaran, serían subclases de las clases Empleado y 
Estudiante. Empleado tiene dos subclases. Académico y Administrador, porque hay atribu¬ 
tos y métodos diferentes para cada una de estas clases especializadas. 

Las subclases se definen mediante verbos especiales. Estos son a menudo palabras se¬ 
guidas, como esun para "es un", esuntipode para "es un tipo de" y puedesenm para "puede 
ser un". 

esun Profesor esun Empleado 

esuntipode Administrador esuntipode Empleado 
puedeserun Empleado puedeserun Profesor 

Cómo identificar clases abstractas Usted podría identificar clases abstractas verificando si 
varias clases o tablas de la base de datos tienen los mismos elementos, o si varias clases tie- 
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Persona 


-apellido 

-nombre 

¿alie' 

-departaméñto : 
-ciudad 

-esfádtf^Sí|ii0 : 
-codígoPostal . 
-telefono ' ; 
-telefonoCelüíar 
-correoElectronicd 


+camb¡arD¡recclón(j 

+dambiárl\ldmbré() 


puedeserun 


I 


puedeserun 


1 esun 

1 


esun 


Estudiante 


Empleado 

-numeroDelEstudiante 

-credltosTerminaclos 

-promedioDeCalificacionGS 

-departamento 

-espeoalzacen ... . 

-especialIzacíonSecundariai 


mumero.DelEmpléado 

-sueldo 

-sueldoÁnualBruto 
-suéldoAnüalMenos -V : . ■ 

: Retenciones 
-fechaContrataclon 

+cambiarEstudiante() 


-departamento 

+buscarEstucliante(). 
+estud¡anteDeLlcenc¡atura() 
-m cía ¡zarO j. ... 
+completarEstud¡ante() , / 


+cambiarEmpleado() : 
+¡mpr¡mlrlnformaclon 
Delmpuestosf) 
+em¡tlrRec¡boDel\lom¡na() 


•.'•i r a¡vt ze es ■ 

tipo mejorado de diagrama de 
clases. 


puedeserun 


i 


jDuedesemn^ 


esun 


Profesor 
-gradoAcademico 
-posición 
-WebURL 


+camb¡arPos.¡Glon() 

+camb¡arURL() 


esuritpodej 

i 


Administrador 


-puesto 


+camb¡arEmpleado() 


nen los mismos métodos. Usted puede crear una clase general extrayendo los atributos y 
métodos comunes, o podría crear una clase especializada para los atributos y métodos úni¬ 
cos. En un ejemplo bancario, un retiro, un pago de un préstamo o un cheque escrito, todos 
tienen el mismo método: sustraen dinero del saldo del cliente. 


Cómo encontrar ciases Existen varias maneras para determinar clases. Se podrían descu¬ 
brir durante entrevistas o sesiones de JAD (que se describieron en el capítulo 4], durante 
sesiones de equipo dirigidas o en sesiones de lluvia de ideas. El análisis de documentos y 
memorandos también podría revelar clases. Una de las maneras más fáciles es usar el mé¬ 
todo de CRC ya descrito en este capítulo. El analista también debe examinar los casos de 
uso en busca de sustantivos. Cada nombre podría conducir a una clase candidata o poten¬ 
cial. Se les llama clases candidatas porque algunos de los nombres podrían ser atributos de 
una clase. 

Debe existir una clase para cada objeto distinto que tenga una definición clara. Pregun¬ 
te lo que la clase sabe, los atributos; y lo que la clase sabe hacer, los métodos. Identifique las 
relaciones de la clase y la multiplicidad para cada extremo de la relación. Si la relación es 
muchos a muchos, cree una intersección o una clase asociativa, similar a la entidad asociati¬ 
va en un diagrama de entidad-relación. 
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Cómo determinar los métodos de la clase El analista debe determinar los atributos y los 
métodos de la clase. Los atributos son fáciles de identificar, pero es más difícil identificar 
los métodos que trabajan con los atributos. Algunos de los métodos son comunes, y siempre 
se asocian con una clase, como nuevoQ, o el método <5(create;s>, que es una extensión de 
UML creada por una persona u organización, conocida como estereotipo. Los símbolos 
<53 A > no son simplemente pares de símbolos mayor que y menor que, sino que se denomi¬ 
nan comillas angulares. 

Otra manera útil de determinar los métodos es examinar una matriz CLAE (vea el ca¬ 
pítulo 7). La figura 18.23 ilustra una matriz CLAE para los ofrecimientos de cursos. Cada 
inicial requiere un método diferente. Si hay una C para crear, agregue un método nuevoQ. 
Si hay una Apara la actualización, agregue un método actualizar() o cambiarf). Si hay una 
E para eliminar, agregue un método eliminarf) o borrarQ. Si hay una L para leer, agregue 
métodos para buscar, ver o imprimir. En el ejemplo mostrado, la clase libro de texto necesi¬ 
taría un método crear para agregar un libro de texto, y un método leer para iniciar una con¬ 
sulta del curso, cambiar un libro de texto o encontrar un libro de texto. Si se reemplazara un 
libro de texto, se necesitaría un método de actualización, y si se eliminara un libro de texto, 
se requeriría un método para eliminar. 

Mensajes Para realizar trabajo útil, la mayoría de las clases necesita comunicarse con las 
demás. Un objeto de una clase necesita enviar información a un objeto de otra clase a tra¬ 
vés de un mensaje, de manera similar a como se realizan las llamadas en un lenguaje de pro¬ 
gramación tradicional. Un mensaje también actúa como un comando, que le indica a la cla¬ 
se receptora que realice alguna tarea. Un mensaje consiste del nombre del método de la clase 
receptora, así como los atributos (parámetros o argumentos) que se pasan con el nombre 
del método. La clase receptora debe tener un método que corresponda con el nombre del 
mensaje. 
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Dado que los mensajes se envían de una clase a otra, es posible considerarlos como en¬ 
trada o salida. La primera clase debe proporcionar los parámetros incluidos en el mensaje y 
la segunda clase los utiliza. Si existe un diagrama de flujo de datos físico hijo para el domi¬ 
nio del problema, podría ayudar a descubrir los métodos. El flujo de datos de un proceso 
primitivo a otro representa el mensaje, y los procesos primitivos deben examinarse como 
métodos candidatos. 


DIAGRAMAS DE ESTADOS 

El diagrama de estados, o de transición de estados, es otra manera de determinar los méto¬ 
dos de una clase. Se usa para examinar los diferentes estados que podría tener un objeto. 

Un diagrama de estados se crea para una sola clase. Por lo general, los objetos se crean, 
sufren cambios y se eliminan. 

Los objetos existen en cualquiera de estos estados, que son las condiciones de un obje¬ 
to en un momento específico. Los valores de los atributos de un objeto definen el estado en 
que se encuentra el objeto, y en ocasiones existe un atributo, como Estado del Pedido (pen¬ 
diente, surtido, empaquetado, enviado, recibido, etc.] que indica el estado. Un estado tiene 
un nombre con cada palabra iniciando con mayúscula. El nombre debe ser único y signifi¬ 
cativo para los usuarios. Un estado también tiene acciones de entrada y salida, las cosas que 
el objeto debe hacer cada vez que entra o sale de un estado determinado. 

Un evento es algo que ocurre en un momento y lugar específicos. Los eventos causan 
un cambio en el estado del objeto, y se dice que se "dispara" una transición. Los estados se¬ 
paran eventos, como en el caso de un pedido que espera ser surtido, y los eventos separan 
estados, como en el caso de un evento Pedido Recibido o Pedido Completo. 

Un evento causa la transición, y ocurre cuando se cumple una condición. Una condición 
es algo que da como resultado verdadero o falso, y puede ser tan sencilla como "Haga clic 
para confirmar el pedido". También puede ser una condición que ocurra en un método, como 
un artículo que esté agotado. Las condiciones se muestran entre corchetes junto a la etique¬ 
ta del evento. 

También hay eventos diferidos, o eventos que sólo se realizan hasta que un objeto cam¬ 
bia a un estado que puede aceptarlos. Un usuario que teclea algo cuando un procesador de 
texto está realizando una copia de seguridad es un ejemplo de un evento diferido. Después 
de que termina la copia de seguridad, el texto aparece en el documento. 

Los eventos se clasifican en tres categorías diferentes: 

1. Señales o mensajes asincronos, que ocurren cuando el programa que realiza la llamada 
no espera un mensaje de respuesta, como en el caso de una característica ejecutada de 
un menú. 

2. Mensajes síncronos, que son llamadas a funciones o subrutinas. El objeto que llama se 
detiene y espera a que el control regrese a él, junto con un mensaje opcional. 

3. Eventos temporales, que ocurren en un momento predeterminado. Por lo general, estos 
eventos no involucran un actor o un evento externo. 

Los objetos materiales tienen persistencia; es decir, existen durante un largo periodo. 
Los vuelos de avión, los conciertos y los eventos deportivos tienen una persistencia más cor¬ 
ta (podrían tener estados que cambian en un periodo más breve]. Algunos objetos, conoci¬ 
dos como objetos temporales, no sobreviven el fin de una sesión. Estos incluyen la memoria 
principal, datos de un URL (o localización] en la Web, páginas Web, pantallas CICS, etc. La 
única manera de guardar objetos temporales es almacenar información relativa a ellos, co¬ 
mo al guardar datos de la Web en una cookie. 

Cada vez que un objeto cambia de estado, algunos de los atributos cambian sus valores. 
Además, cada vez que cambian los atributos de un objeto, debe haber un método para cam¬ 
biarlos. Cada uno de los métodos necesitaría una pantalla o formulario Web para agregar o 
cambiar los atributos. Estos se convierten en los objetos de la interfaz. Con frecuencia, la 
pantalla o formulario Web tendría más controles (o campos] que simplemente los atributos 
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que cambian. Por lo general, tendrían claves principales, información de identificación (co¬ 
mo un nombre o dirección) y otros atributos necesarios para una buena interfaz de usuario. 
La excepción es un evento temporal, el cual podría usar tablas de la base de datos o una 
cola que contenga la información. 


EJEMPLO DE UNA TRANSICIÓN DE ESTADO 

Considere a un estudiante que se matricula en una universidad y los diversos estados por los 
que tendría que atravesar. Tres de los estados se listan en detalle a continuación: 


Estado: 

Evento: 

Método: 

Atributos modificados: 


Interfaz de usuario: 


Estudiante Potencial 
Solicitud Enviada 
nuevo() 

Número 

Nombre 

Dirección 

Formulario Web de Solicitud del Estudiante 


Estado: 

Evento: 

Método: 

Atributos modificados: 


interfaz de usuario: 


Estudiante Aceptado 
Requisitos Cumplidos 
ac ep tarEs tudi ante () 

Fecha de Admisión 
Estado del Estudiante 
Devolver Carta de Aceptación 
Pantalla para Aceptar al Estudiante 


Estado: 

Evento: 

Método: 

Atributos modificados: 


Interfaz de usuario: 


Dormitorio Asignado al Estudiante 
Dormitorio Seleccionado 
asignarDormitorio() 

Nombre de Dormitorio 

Dormitorio 

Plan de Comidas 

Pantalla para Asignar Dormitorio al Estudiante 


Los otros estados son Estudiante del Programa, Estudiante Actual, Estudiante Perma¬ 
nente y Estudiante de Licenciatura. Cada estado tendría un evento, métodos, atributos 
modificados y una interfaz de usuario asociada. Esta serie de estados se puede usar para de¬ 
terminar los atributos y métodos que conforman la clase. 

Los estados y eventos que activan los cambios se podrían representar en un diagrama 
de estados (o un diagrama de transición de estados). En la figura 18.24 se ilustra el diagra¬ 
ma de estados para el Estudiante. Los estados se representan mediante rectángulos, y los 
eventos o actividades son las flechas que unen los estados y causan que un estado cambie a 
otro estado. Los eventos de transición se nombran en pasado, porque ya ocurrieron para 
crear la transición. 

No se crean diagramas de estados para todas las clases. Estos diagramas se crean 
cuando: 


1. Una clase tiene un ciclo de vida complejo. 

2. Una instancia de una clase podría actualizar sus atributos de varias maneras a través de 
su ciclo de vida. 

3. Una clase tiene un ciclo de vida operacional. 

4. Dos clases dependen entre sí. 

5. El comportamiento actual del objeto depende de lo que haya ocurrido antes. 

Cuando examine un diagrama de estados, aproveche la oportunidad para buscar erro¬ 
res y excepciones. Inspeccione el diagrama para ver si los eventos ocurren en un momento 
equivocado. También revise si todos los eventos y estados se han representado. Los diagra- 
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mas de estados sólo tienen que evitar dos problemas. Asegúrese de que un estado no tenga 
todas las transiciones dirigiéndose hacia el estado o todas sus transacciones saliendo del mismo. 

Cada estado debe tener por lo menos una transición que entre y salga de él. Algunos 
diagramas de estados utilizan los mismos símbolos de inicio y terminación que los diagra¬ 
mas de actividades: un círculo sólido representa el inicio y círculos concéntricos con el cen¬ 
tro sólido indican el final del diagrama. 


PAQUETES Y OTROS ARTEFACTOS DE UML 

Los paquetes son los contenedores para otros elementos de UML, como los casos de uso o las 
clases. Los paquetes pueden mostrar el particionamiento del sistema, indicando cuáles clases 
o casos de uso se agrupan en un subsistema, y se conocen como paquetes lógicos. También 
pueden ser paquetes de componentes [los cuales contienen los componentes físicos del siste¬ 
ma) o paquetes de casos de uso (que contienen un grupo de casos de uso). Los paquetes usan 
un símbolo de carpeta con el nombre del paquete en la pestaña de la carpeta o centrado en 
esta última. La creación de los paquetes se puede realizar durante el análisis de sistemas, o 
más tarde en la etapa de diseño del sistema. Los paquetes también podrían tener relaciones, 
de manera similar a los diagramas de clases, que podrían incluir asociaciones y herencia. 

La figura 18.25 constituye un ejemplo de un diagrama de paquete de casos de uso. 
Muestra que cuatro casos de uso. Agregar Estudiante, Matricularse en la Clase, Transferir 
Créditos y Ver Información del Estudiante, forman parte del paquete Estudiante. Hay tres 
casos de uso. Agregar Profesor, Ver Información del Profesor y Asignar Profesor al Curso 
que son parte del paquete Profesor. 
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Conforme usted continúe construyendo diagramas, necesitará utilizar diagramas de 
componentes, diagramas de despliegue y elementos o cosas de anotación. Éstos permiten 
perspectivas diferentes en el trabajo que se realiza. 

Él diagrama de componentes es similar a un diagrama de clases, pero da una visión más 
general de la arquitectura del sistema. El diagrama de componentes muestra los componen¬ 
tes del sistema, como un archivo de clases, un paquete, las bibliotecas compartidas, una base 
de datos, etc., y cómo se relacionan entre sí. Los componentes individuales de un diagrama de 
componentes se consideran en más detalle dentro de otros diagramas de UML, como los 
diagramas de clases y los diagramas de casos de uso. 

El diagrama de despliegue ilustra la implementación física del sistema, incluyendo el 
hardware, las relaciones entre el hardware y el sistema en que se despliega. El diagrama de 
despliegue puede mostrar servidores, estaciones de trabajo, impresoras, etcétera. 

Los elementos o cosas de anotación dan más información sobre el sistema a los desa¬ 
rrolladores. Consisten en notas que pueden adjuntarse a cualquier elemento de UML: ob¬ 
jetos, comportamientos, relaciones, diagramas, o cualquier cosa que requiera descripciones 
detalladas, suposiciones o información relativa al diseño y funcionamiento del sistema. El 
éxito de UML depende de que la documentación del modelo del sistema sea suficiente¬ 
mente completa y precisa para proporcionar la información necesaria al equipo de desa¬ 
rrollo. Las notas proporcionan una fuente de conocimiento y comprensión común sobre el 
sistema, que es útil para coordinar a los desarrolladores. Las notas se muestran como un 
símbolo de papel con una esquina doblada y una línea que las conecta con el área que re¬ 
quiere atención. 
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analista de sistemas maneje las herramientas. El analista usará en principio el conjunto de 
herramientas de UML para dividir los requerimientos del sistema en un modelo de casos 
de uso y un modelo de objetos. El modelo de casos de uso describe a los casos de uso y los 
actores. El modelo de objetos describe los objetos, así como sus asociaciones, responsabilida¬ 
des, colaboradores y atributos. 

1. Defina el modelo de casos de uso. 

• Busque los actores en el dominio del problema revisando los requerimientos del 
sistema y entrevistando a algunos expertos de negocios. 

9 Identifique los eventos principales iniciados por los actores y desarrolle un 
conjunto de casos de uso primarios a un nivel muy alto que describa los eventos 
desde la perspectiva de cada actor. 

9 Desarrolle los diagramas de casos de uso para aclarar la manera en que los 
actores se relacionan con los casos de uso que definirán el sistema. 

9 Refine los casos de uso primarios para desarrollar una descripción detallada de la 
funcionalidad del sistema para cada caso de uso primario. Proporcione detalles 
adicionales desarrollando escenarios de caso de uso que documenten los flujos 
alternos de los casos de uso primarios. 

8 Revise los escenarios de caso de uso con los expertos del área de negocios para 
verificar los procesos y las interacciones. Haga las modificaciones necesarias hasta 
que los expertos del área de negocios coincidan en que los escenarios de caso de 
uso están completos y exactos. 

2. Continúe la elaboración de diagramas de UML para modelar el sistema durante la fase 

de análisis. 

8 Derive diagramas de actividades a partir de los diagramas de casos de uso. 

9 Desarrolle diagramas de secuencias y de colaboración a partir de los escenarios 
de caso de uso. 

• Revise los diagramas de secuencias con los expertos del área de negocios para 
verificar los procesos y las interacciones. Haga las modificaciones necesarias hasta 
que los expertos del área de negocios coincidan en que los diagramas de secuen¬ 
cias están completos y exactos. Esta revisión adicional de los diagramas de 
secuencias gráficos a menudo proporciona a los expertos del área de negocios 
una oportunidad para reconsiderar y refinar los procesos con mayor detalle que 
en la revisión a los escenarios de caso de uso. 

3. Desarrolle los diagramas de clases. 

9 Busque sustantivos en los casos de uso y haga una lista. Los sustantivos son obje¬ 
tos potenciales. Una vez que los identifique, busque similitudes y diferencias en 
el estado o el comportamiento de los objetos, y a continuación elabore las clases. 

9 Defina las principales relaciones entre las clases. Busque relaciones "tiene un" y 
"es un" entre las clases. 

9 Examine los diagramas de casos de uso y de secuencias con el fin de determinar 
las clases. 

9 Empezando con los casos de uso más importantes para el diseño del sistema, cree 
diagramas de clases que muestren las clases y relaciones que existen en los casos 
de uso. Un diagrama de clases podría representar las clases y relaciones descritas 
en diversos casos de uso relacionados. 

4. Dibuje diagramas de estados. 

8 Desarrolle diagramas de estados para algunos diagramas de clases con el 
propósito de proporcionar un análisis más profundo del sistema en este punto. 
Utilice diagramas de estados para comprender procesos complejos que no 
pueden derivarse totalmente a partir de los diagramas de secuencias. 

• Determine métodos examinando los diagramas de estados. Derive atributos de la 
clase (datos) de un estado a partir de casos de uso, expertos del área de negocios 
y métodos de la clase. Indique si los métodos y atributos de la clase son públicos 
(accesibles externamente) o privados (interior a la clase). Los diagramas de esta¬ 
dos son sumamente útiles para modificar diagramas de clases. 
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5. Comience el diseño de sistemas refinando los diagramas de UML, y utilícelos para de¬ 
rivar clases y sus atributos y métodos. 

• Revise todos los diagramas de UML que haya en el sistema. Escriba especifica¬ 
ciones para cada clase, incluyendo sus atributos, métodos y descripciones. Revise 
los diagramas de secuencias para identificar otros métodos de clase. 

• Desarrolle especificaciones que detallen los requerimientos de entrada y salida 
de los métodos, junto con una descripción detallada del procesamiento interno del 
método. 

• Elabore otro conjunto de diagramas de secuencias (si es necesario] para reflejar 
los métodos de la clase actual y la manera en que interactúan entre sí y con las 
interfaces del sistema. 

6 Genere diagramas de clases utilizando los símbolos de clase especializados para 
las clases de límite o de interfaz, las clases de entidad y las clases de control. 

• Analice los diagramas de clases para derivar los componentes del sistema; es 
decir, clases que tengan relación funcional y lógica y que se compilarán y desple¬ 
garán juntas como una biblioteca (.DLL), un objeto .COM, un bean de Java, un 
paquete, etcétera. 

• Desarrolle diagramas de despliegue para indicar la manera en que se desplegarán 
los componentes de su sistema en el ambiente de producción. 

6. Documente en detalle el diseño de su sistema. Este paso es crucial. Entre más comple¬ 
ta sea la información que proporcione al equipo de desarrollo a través de la documen¬ 
tación y diagramas de UML, más rápido será el desarrollo y más sólido será el sistema 
final. 


LA IMPORTANCIA DE USAR UiL PARA EL MODELADO 


El UML es una herramienta poderosa que puede mejorar en gran medida la calidad del aná¬ 
lisis y diseño de su sistema, y puede esperarse que las prácticas mejoradas se traduzcan en 
sistemas de mayor calidad. 

Al utilizar el UML de manera iterativa en el análisis y el diseño, usted puede conse¬ 
guir que los equipos de negocios y de TI comprendan mucho mejor los requerimientos 
del sistema y los procesos que se tienen que realizar en el sistema para cumplir tales re¬ 
querimientos. 

La primera iteración de análisis debe darse en un nivel muy alto para identificar los 
objetivos generales del sistema y validar los requerimientos a través del análisis de los ca¬ 
sos de uso. La identificación de los actores y la definición del modelo de caso de uso ini¬ 
cial son parte de esta primera iteración. Las iteraciones de análisis subsecuentes refinan 
aún más los requerimientos del sistema a través del desarrollo de escenarios de caso de 
uso, diagramas de clases, diagramas de secuencias, diagramas de estados, etc. En cada ite¬ 
ración se realiza una revisión más detallada del diseño del sistema hasta que las cosas y las 
relaciones del sistema se encuentran definidas de una manera clara y precisa en los docu¬ 
mentos de UML. 

Cuando su análisis y diseño estén terminados, usted debe tener un conjunto de especi¬ 
ficaciones preciso y detallado de las clases, escenarios, actividades y secuencias del sistema. 
En general, usted puede determinar la minuciosidad del análisis y el diseño de un sistema 
según la cantidad de tiempo requerido para desarrollarlo y la calidad resultante del produc¬ 
to entregado. 

Al desarrollar un sistema, a menudo se ignora el hecho de que entre más progrese un 
proyecto, más costosos serán los cambios a los requerimientos de negocios del sistema. 
Cualquier cambio al diseño de un sistema con una herramienta CASE, o incluso en papel, 
durante las fases de análisis y diseño de un proyecto es más sencillo, más rápido y mucho 
menos costoso que hacerlo durante la fase de desarrollo del proyecto. 

Desafortunadamente algunos empresarios tienen poca visión y creen que un progra¬ 
mador o analista sólo trabaja cuando está codificando. Algunos empresarios suponen erró- 
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RESUMEN 

Los sistemas orientados a objetos describen las entidades como objetos. Éstos son parte 
de un concepto general llamado clases, la unidad principal de análisis en el análisis y dise¬ 
ño orientado a objetos. Cuando se introdujo por primera vez el enfoque orientado a objetos, 
sus partidarios citaron la reusabilidad de los objetos como su principal beneficio. Aunque 
la reusabilidad es la meta principal, el mantenimiento de los sistemas también es muy 
importante. 

Los analistas pueden usar tarjetas CRC para empezar el proceso de modelado de obje¬ 
tos de una manera informal. Es posible agregar pensamiento del objeto a las tarjetas CRC 
para ayudar al analista a refinar responsabilidades en tareas más y más pequeñas. Las sesio¬ 
nes de CRC se pueden realizar con un grupo de analistas para determinar las clases y las res¬ 
ponsabilidades de manera interactiva. 

El lenguaje de modelado unificado (UML) proporciona un conjunto estandarizado 
de herramientas para documentar el análisis y diseño de un sistema de software. El UML se 
basa esencialmente en una técnica orientada a objetos conocida como modelado de casos 
de uso. Un modelo de caso de uso describe lo que hace un sistema sin describir cómo lo 
hace. Un modelo de caso de uso divide la funcionalidad de un sistema en comportamien¬ 
tos (conocidos como casos de uso) significativos para los usuarios del sistema (llamados 
actores}. Se crean diferentes escenarios para cada conjunto diferente de condiciones de 
un caso de uso. 

Los principales componentes de UML son cosas, relaciones y diagramas. Los diagramas 
se relacionan entre sí. Las cosas estructurales son las más comunes; entre ellas se encuentran 
las clases, las interfaces, los casos de uso y muchos otros elementos que proporcionan una 
manera de crear modelos. Las cosas estructurales permiten al usuario describir relaciones. 
Las cosas relativas al comportamiento describen cómo trabajan las cosas. Las cosas agrupa¬ 
das se usan para definir límites. Las cosas de anotación permiten al analista agregar notas a 
los diagramas. 

Las relaciones constituyen el pegamento que une las cosas. Las relaciones estructurales 
se utilizan para enlazar las cosas en los diagramas estructurales. Las relaciones estructura¬ 
les incluyen dependencias, agregaciones, asociaciones y generalizaciones. Los diagramas de 
comportamiento usan los cuatro tipos básicos de relaciones de comportamiento: comunica, 
incluye, extiende y generaliza. 

El conjunto de herramientas de UML está compuesto de diagramas de UML. Entre és¬ 
tos se incluyen diagramas de caso de uso, de actividades, de secuencias, de colaboración, de 
clases y de estado. Además de los diagramas, los analistas pueden describir un caso de uso 
mediante un escenario de caso de uso. 

Al usar el UML de manera iterativa en el análisis y el diseño, usted puede lograr que los 
equipos de negocios y de tecnología de la información comprendan mucho mejor los reque¬ 
rimientos del sistema y los procesos que se tienen que realizar en este último para satisfacer 
los requerimientos. 


PALABRAS Y FRASES CLAVE 

actor 

agregación 

asociación 

barra de sincronización 

bifurcación 

carril 

caso de uso primario 
clase 


clase abstracta 
clase de control 
clase de entidad 
clase límite 
colaboración 
comunica 
cosa de anotación 
dependencias 



ANÁLISIS Y DISBSD DE SISTEMAS OTENTADO A OBJETOS USANDO EL LENGUAJE UNIFICADO DE MODELACIÓN (UML) 









diagrama de actividades 
diagrama de casos de uso 
diagrama de clases 
diagrama de colaboración 
diagrama de despliegue 
diagrama de estados 
diagrama de secuencias 
escenario de caso de uso 
estado 

estructura todo/parte 
evento 

evento temporal 
extiende 
fusión 
generaliza 

generalización/especialización 

(gen/esp) 

herencia 


incluye 

lenguaje de modelado unificado (UML) 
mensaje 

mensaje asincrono 
mensaje síncrono 
objeto 

orientado a objetos 
paquete 
polimorfismo 
proceso unificado 
rama 

redefinición de métodos 

relación 

ruta feliz 

ruta principal 

sobrecarga de métodos 

tarjetas CRC 

unión 


PREGUNTAS DE REPASO 

1. Mencione dos razones para adoptar un enfoque orientado a objetos para el desarrollo 
de sistemas. 

2. Describa la diferencia entre una clase y un objeto. 

3. Explique el concepto de herencia en los sistemas orientados a objetos. 

4. ¿Qué significa CRC? 

5. Describa lo que aporta el Pensamiento del Objeto a la tarjeta CRC. 

6. ¿Qué es el UML? 

7. ¿Cuáles son los tres elementos principales de UML? 

8. Mencione qué incluye el concepto de cosas estructurales. 

9. Mencione qué incluye el concepto de cosas del comportamiento. 

10. ¿Cuáles son los dos tipos principales de diagramas en UML? 

11. Mencione qué diagramas se incluyen en los diagramas estructurales. 

12. Mencione qué diagramas se incluyen en los diagramas del comportamiento. 

13. ¿Qué describe un modelo de caso de uso? 

14. ¿Usted describiría a un modelo de caso de uso como modelo lógico o físico del sistema? 
Argumente su respuesta en un párrafo. 

15. Defina lo que es un actor en un diagrama de caso de uso. 

16. ¿Cuáles son las tres cosas que siempre debe describir un caso de uso? 

17. ¿En los diagramas de casos de uso, qué tipo de relaciones constituyen comunica, inclu¬ 
ye, extiende y generaliza? 

18. ¿Cuáles son dos nombres adicionales para el caso de uso primario? 

19. ¿Cuáles son las tres áreas principales que se proporcionan en un caso de uso primario? 

20. ¿Qué describe un diagrama de actividades? 

21. Describa en un párrafo cuál es la utilidad de los carriles en los diagramas de actividades. 

22. ¿Qué puede ilustrarse en un diagrama de secuencias o de colaboración? 

23. ¿Por qué la definición de clases es una tarea importante en el análisis orientado a objetos? 

24. ¿Qué puede mostrarse en un diagrama de clases? 

25. Defina la sobrecarga de métodos. 

26. Mencione las cuatro categorías en las que se dividen las clases. 

27. ¿Cuáles son las dos categorías de relaciones entre las clases? 

28. ¿Para qué se usan los diagramas de gen/esp? 

29. ¿De qué otra manera se conoce el polimorfismo? 

30. ¿Qué describe un diagrama de estados? 

31. ¿Qué es un paquete en el enfoque de UML? 

32. ¿Por qué es importante utilizar el UML para modelar? 
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PROBLEMAS 

1. Elabore una serie de tarjetas CRC para la División de Catálogos de World's Trend. Una 
vez que se realiza un pedido, el personal dedicado al cumplimiento de pedidos se hace 
cargo de él y revisa la disponibilidad, surte el pedido y calcula el total del mismo. Utilice 
cinco tarjetas CRC, una para cada una de las siguientes clases: pedido, cumplimiento 
del pedido, inventario, producto y cliente. Complete la sección de clases, responsabili¬ 
dades y colaboradores. 

2. Termine las tarjetas CRC del problema 1 creando enunciados de pensamiento del ob¬ 
jeto y nombres de las propiedades para cada una de las cinco clases. 

3. Dibuje un diagrama de casos de uso para la División de Catálogos de Wolrd's Trend. 

4. Para el problema de FilmMagic de la Oportunidad de consultoría 18.1, dibuje un dia¬ 
grama de clases en UML. 

5. Para el problema de FilmMagic de la Oportunidad de consultoría 18.1, dibuje un dia¬ 
grama de estados para (a) Cliente y (b) Vídeo. 

6. Dibuje cuatro ejemplos que muestren cuatro tipos de relaciones de comportamiento 
para el concesionario de automóviles BMW Joel Porter's. ¿Qué tipo de relación se re¬ 
quiere cuando un cliente debe solicitar financiamiento? ¿Hay actividades comunes 
cuando una persona arrienda o compra un automóvil? ¿Qué tipo de relación se da en¬ 
tre un empleado que se desempeña como gerente o uno que es vendedor? 

7. Dibuje un diagrama de colaboración para un estudiante que toma un curso de un 
maestro que es miembro de la facultad. 

8. El condado de Coleman tiene un conmutador telefónico que maneja las interconexio¬ 
nes de las llamadas entre quienes las realizan y quienes las reciben. Dados estos tres ac¬ 
tores, dibuje un diagrama de secuencias sencillo para hacer una llamada telefónica. 

9. Usted está listo para empezar el modelado de UMF para la Clínica Kirt. Dibuje un dia¬ 
grama de clases que incluya a un médico, un paciente, una cita y la factura de un pa¬ 
ciente. No involucre a la compañía de seguros. 

10. Use el UMF para dibujar ejemplos de las cuatro relaciones estructurales para la Clínica 
Kirt. 

11. Escriba un escenario de caso de uso para un paciente que ve a un médico de la Clíni¬ 
ca Kirt. 
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Los números entre paréntesis hacen referencia al capítulo en el cual se define el término. 

ACOPLAMIENTO DE DATOS Representación del paso de datos entre dos módulos 
en un diagrama de estructura. (16) 

ACTOR En UML, papel particular de un usuario del sistema. El actor existe fuera del 
sistema e interactúa con éste de una manera específica. Un actor puede ser una persona, 
otro sistema, o un dispositivo como un teclado o un módem. (18) Véase también caso 
de uso. 

ADMINISTRACIÓN DE LA CADENA DE ABASTECIMIENTO Esfuerzo de una orga¬ 
nización para integral - sus requerimientos de administración de proveedores, distribui¬ 
dores y clientes en un proceso unificado. Las aplicaciones de comercio electrónico 
pueden mejorar la administración de la cadena de abastecimiento. [17] 

ADMINISTRACIÓN DE PROYECTOS Arte y ciencia de planear un proyecto, es t imar 
costos y calendarios, administrar el riesgo, y organizar y supervisar un equipo. Hay mu¬ 
chos paquetes de software para apoyar las tareas de administración de proyectos. (3) 

ADMINISTRADOR DE PROYECTOS Persona responsable de supervisar la planea- 
ción, costeo, calendarización y organización del equipo de un proyecto (de sistemas). 
Con frecuencia, este papel lo desempeña un analista de sistemas. (3) 

AGREGACIÓN Con frecuencia se describe como una relación del tipo "tiene un" al 
utilizar UML con un enfoque orientado a objetos. Las agregaciones ofrecen un medio 
para demostrar que un objeto completo se compone de la suma de sus partes (otros ob¬ 
jetos). (18) 

ALIAS Nombre alterno para un dato utilizado por diferentes usuarios. Se registra en 
un diccionario de datos. (8) 

ALMACEN DE DATOS Colección de datos utilizada para apoyar - los procesos de toma 
de decisiones administrativas, orientada a temas, integrada, que cambia con el tiempo y 
no volátil. (14) Véase también minería de datos. 

ANALISTA DE SISTEMAS Persona encargada de evaluar sistemáticamente el fun¬ 
cionamiento de los negocios mediante el examen de la entrada y procesamiento de los 
datos, así como la sahda de información, con el propósito de perfeccionar - los procesos de 
una organización. (1) 

APPLETS DE JAVA Pequeño programa de aplicación, escrito en lenguaje Java, que 
puede incrustarse en un documento HTML para ser usado en páginas Web. (11) 

ARBOL DE DECISIONES Método de anáfisis de decisiones para decisiones estructu¬ 
radas. Es un enfoque apropiado cuando las acciones se deben realizar - en una secuencia 
determinada. (9) 

ARQUITECTURA CLIENTE7SERVIDOR Modelo de diseño que presenta aplicaciones 
que se ejecutan en una red de área local (LAN). Las computadoras de la red dividen las 
tareas de procesamiento entre los servidores y clientes. Los clientes son máquinas co¬ 
nectadas a la red que constituyen puntos de entrada al sistema cliente/servidor. (17) 

ATRIBUTO Una característica de una entidad. Cada entidad puede tener muchos 
atributos. (13) Véase también dato. 








BANDERA DE CONTROL Utilizada en diagramas de estructura, una bandera de con¬ 
trol decide qué parte de un módulo se ejecuta y está asociada con IF, THEN, ELSE y 
con otros tipos de instrucciones similares. (16) 

BASE DE DATOS Almacén de datos electrónicos formalmente definido y central¬ 
mente controlado cuyo propósito es ser usado en muchas aplicaciones diferentes. (13) 

BENEFICIOS INTANGIBLES Beneficios, difíciles de cuantificar en dinero, que consi¬ 
gue la organización al utilizar un nuevo sistema de información, como mejor toma de 
decisiones, mayor exactitud y mayor competitividad. (10) Véase también beneficios 
tangibles, costos intangibles, costos tangibles. 

BENLUCIOS TANGIBLES Ventajas cuantificables en dinero que consigue la orga¬ 
nización a través del uso de sistemas de información. (10) Véase también beneficios 
intangibles. 

BOTON DE OPCION Uno de los diversos elementos de diseño de una GUI que 
proporciona un botón para elegir una opción en un cuadro de diálogo. Los botones de 
opción son mutuamente excluyentes, ya que el usuario sólo puede seleccionar uno 
de ellos de entre un grupo. (11) 

CAMPO Parte física de una base de datos que se puede llenar con diversos elementos 
de datos. Es la unidad más pequeña de datos de una aplicación que es reconocida por 
el software del sistema. (13) 

CARRILES Los caniles son zonas que se utilizan en diagramas de actividades para in¬ 
dicar particiones. Los caniles pueden mostrar qué actividades se realizan en cuál plata¬ 
forma, qué grupo las realiza, y también pueden ilustrar la lógica del sistema. (18) 

CASO DE USO En UML, secuencia de transacciones en un sistema. El propósito del 
caso de uso es producir algo de valor para un actor del sistema. El modelo de casos de 
uso se basa en las interacciones y relaciones de los casos de uso individuales. En un 
caso de uso, un actor que utiliza el sistema inicia un evento que desencadena una serie de 
interacciones relacionadas en el sistema. Un caso de uso se enfoca en lo que hace el sis¬ 
tema más que en la forma como lo hace. (18) 

CICLO DE VIDA DEL DESARROLLO DE SISTEMAS (SDLC) Método de siete fases 
para el análisis y diseño de sistemas cuya premisa es que los sistemas se desarrollan de una 
mejor manera mediante un ciclo específico de actividades del analista y el usuario. (1) 

CLASE Plantilla común para un grupo de objetos individuales con atributos y com¬ 
portamientos similares en el análisis y diseño orientado a objetos y UML. (18) 

CLASE DE OBJETOS Una clase es una categoría de objetos similares. Los objetos se 
agrupan en clases. Una clase define los atributos y comportamientos que comparte 
cada objeto de la clase. (18) 

CLAVE (LLAVE) Uno de los elementos de datos de un registro que se utiliza para 
identificar al registro. (13) Véase también clave primaria, clave secundarla. 

CLAVE (LLAVE) PRIMARIA Clave que identifica de manera única un registro. (13) 
Véase también clave, clave secundarla. 

CLAVE (LLAVE) SECUNDARIA Clave que no identifica de manera única un regis¬ 
tro. Una clave secundaria sirve para seleccionar' un grupo de registros pertenecientes a 
un subconjunto. (13) 

í- 

CODIGO NEMONICO Cualquier código (a menudo mediante una combinación de 
letras y símbolos) que ayuda al capturista de datos a recordar' la manera correcta de in¬ 
troducir sus datos o que ayuda al usuario a recordar cómo usar' la información. (15) 

COMERCIO ELECTRÓNICO (e-COmmerce) Realización de negocios a través de 
medios electrónicos, como el correo electrónico, tecnologías de la Web, BBS, tarjetas in¬ 
teligentes, EFT y EDI, entre proveedores, clientes, dependencias gubernamentales y 
otras clases de empresas, con el propósito de dirigñ' y ejecutar' transacciones en activi¬ 
dades comerciales, administrativas y referentes al consumidor. (1) 

COMPORTAMIENTO Representa la forma en que actúa y reacciona un objeto. (18) 


■ GLOSARIO 





CONSULTAS Preguntas que el usuario hace a una base de datos en relación con los 
datos que ésta contiene. Cada consulta implica una entidad, un atributo y un valor. (14) 

CONVERSION Cambio físico de un sistema de información viejo por el nuevo. Hay 
cinco estrategias de conversión: conversión directa, conversión en paralelo, conversión 
por fases o gradual, conversión por prototipos modulares y conversión distribuida. (17) 

COSAS En UML, las cosas describen los objetos del anáhsis y diseño orientado a ob¬ 
jetos. Los dos grupos de cosas que se utilizan con más frecuencia son las cosas estructu¬ 
rales y las cosas conductuales. (18) 

COSTOS INTANGIBLES Costos difíciles de estimar y que tal vez no se conozcan. In¬ 
cluyen la pérdida de la ventaja competitiva, pérdida de la reputación por innovación y la 
caída de la imagen de la compañía, debido a información inoportuna o inaccesible. (10] 

COSTOS TANGIBLES Los costos en dinero requeridos para desarrollar un nuevo sis¬ 
tema que el anabsta de sistemas puede proyectar con precisión. Incluye los costos de 
computadoras, recursos, el tiempo de analistas y programadores, así como los salarios 
de otros empleados. (10) Véase también costos intangibles. 

CREACION DE PROTOTIPOS Proceso rápido e interactivo entre usuarios y anahstas 
para crear y refinar las parles de un nuevo sistema. Se utiliza como parte del ciclo de vi¬ 
da del desarrollo de sistemas (SDLC) para determinar' los requerimientos o como alter¬ 
nativa al SDLC. (6) Véase también desarrollo rápido de aplicaciones. 

DATO La unidad más pequeña en un archivo o base de datos. Usado de manera indis¬ 
tinta con el término atributo. 

DATOS ALMACENADOS Datos que se encuentran en reposo, sin utilizar', en el siste¬ 
ma; se representan mediante un rectángulo con un extremo abierto en los diagramas de 
flujo de datos. (7) 

DEPOSITO DE DATOS Base de datos centralizada que contiene todos los diagramas, 
definiciones de formularios e informes, estructuras de datos, definiciones de datos, flujos 
y lógica de procesos, y definiciones de otros componentes organizacionales y del sistema. 
El depósito provee un conjunto de mecanismos y estructuras para lograr una integra¬ 
ción fluida de datos a herramientas y de datos a datos. (8) 

DESARROLLO RÁPIDO DE APLICACIONES (RAD) Enfoque orientado a objetos 
para el desarrollo de sistemas que incluye un método de desarrollo así como herra¬ 
mientas de software. (6) Véase también creación de prototipos. 

DESNQRMAL5ZAGSQN Definición de registros físicos en un formato que no sea en 
tercera forma normal o en alguna superior. Incluye la unión de atributos de varias rela¬ 
ciones para evitar' el costo de acceder a varios archivos. El particionamiento es una 
forma intencional de desnormalización. (13) 

DIAGRAMA DE BURBUJA Diagrama sencillo que muestra asociaciones de datos entre 
elementos de datos. Cada entidad se encierra en una elipse, y se utilizan flechas para 
mostrar las relaciones. También se conoce como diagrama de modelo de datos. (13) 

DIAGRAMA DE CLASES Utilizado para modelar' gráficamente la vista estática del di¬ 
seño estructural de un sistema. Los diagramas de clases ilustran los requerimientos fun¬ 
cionales del sistema, recabados mediante el anáhsis y el diseño físico del sistema. (18) 

DIAGRAMA DE ENTIDAD-RELACIÓN (E-R) Representación gráfica de un modelo 
E-R. (8) 

DIAGRAMA DE ESTADOS En UML, un medio para refinar aún más los requeri¬ 
mientos. (18) 

DIAGRAMA DE ESTRUCTURA Herramienta para diseñar' un sistema modular, de 
arriba abajo, conformado por cuadros rectangulares y flechas para conectarlos. (16) 
Véase también bandera de control, acoplamiento de datos. 

DIAGRAMA DE FLUJO DE DATOS (DFD) Representación gráfica de los procesos de 
datos, flujos de datos y almacenes de datos en un sistema de negocios. (7) 
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DIAGRAMA DE FLUJO DE DATOS DE CONTEXTO Es el diagrama de flujo de datos 
más básico de una organización. Muestra la manera en que los procesos transforman los 
datos de entrada en infoimación de salida. También se conoce como modelo del entor¬ 
no. (2) Véase también diagrama de flujo de datos. 

DIAGRAMA DE NIVEL 0 Expansión (o descomposición) del diagrama de flujo de da¬ 
tos de contexto, que muestra de tres a nueve procesos principales, flujos de datos im¬ 
portantes y a lm acenes de datos del sistema que se estudia. (7) 

DIAGRAMA DE OBJETOS Diagramas, similares a los diagramas de clases, pero que 
representan el estado de las instancias de clases y sus relaciones en un punto en el tiempo. 
El diagrama de objetos también indica la opcionalidad (el cliente puede tener cero o 
más contratos de alquiler) y cardinalidad (un contrato de alquiler puede tener sólo un 
cliente). (18) 

DIAGRAMA DE SECUENCIAS En UML, un diagrama de secuencias ilustra una su¬ 
cesión de interacciones entre las instancias de un objeto con el paso del tiempo. Con 
frecuencia se utiliza para ilustrar el proceso descrito en escenarios de casos de uso. (18) 

DIAGRAMA FÍSICO DE FLUJO DE DATOS Diagrama que muestra cómo debe im- 
plementarse un sistema, tomando en cuenta el hardware, el software, los usuarios y los 
archivos. (7) Véase también diagrama lógico de flujo de datos. 

DIAGRAMA HIJO Diagrama que resulta de la expansión del proceso en el Diagrama 0 
(llamado proceso padre). (7) 

DIAGRAMA LÓGICO DE FLUJO DE DATOS Diagrama que se enfoca en los negocios 
y cómo funcionan éstos. Describe los eventos de negocios que tienen lugar y los datos 
requeridos y producidos por cada evento. (7) Véase también diagrama de flujo de da¬ 
tos, diagrama físico de flujo de datos. 

DIAGRAMA PERT Herramienta utilizada para determinar actividades críticas para 
un proyecto. Se emplea para mejorar el calendario de un proyecto y evaluar los avan¬ 
ces. Significa Program Evaluation Review Technique (Técnica de Evaluación y Revisión 
de Programas). (3) 

DICCIONARIO DE DATOS Obra de consulta acerca de los datos (metadatos), generada 
por el analista de sistemas con base en los diagramas de flujo de datos. El diccionario 
recopila y coordina términos específicos de datos, confumando lo que cada término 
significa para las diferentes personas de la organización. (8) 

f 

DIRECCION IP La dirección de Protocolo Internet es el número utilizado para re¬ 
presentar a una computadora en una red. El formato de una dirección IP es 
999.999.999.999.(17) 

DISEÑO CONJUNTO DE APLICACIONES (JAD) Metodología de IBM para realizar 
el análisis de requerimientos mediante entrevistas en paneles con analistas, usuarios y 
ejecutivos. (4) 

DOCUMENTACIÓN Material impreso, generado por el analista, mediante el cual des¬ 
cribe cómo se ejecuta el software, da una visión general del sistema o detalla el código 
del programa que se utiliza. Los analistas pueden emplear una herramienta CASE para 
facilitar la generación de la documentación. (16) 

ELEMENTO DE DATOS Pieza simple de datos. Puede ser un elemento base o un ele¬ 
mento derivado. Un elemento de datos debe definirse en el diccionario de datos. (8) 

ENCAPSIJ1 .A MIE NTO En el análisis y diseño orientado a objetos, se encapsula el 
comportamiento de un objeto. Un objeto conserva datos relacionados con las cosas reales 
que representa. A los objetos se les debe indicar o pedir mediante mensajes que modi¬ 
fiquen sus propios datos. (18) 

ENCRIPTACION Se refiere al proceso de convertir un mensaje común, mediante una 
clave, en un mensaje encriptado, de tal manera que una persona sea incapaz de leer el 
mensaje. El destinatario deseado puede utilizar otra clave para descifrar y leer el men¬ 
saje encriptado. (13) 
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ENTIDAD Persona, grupo, departamento o sistema que puede recibir u original' in¬ 
formación o datos. Uno de los principales símbolos de un diagrama de flujo de datos. 
[2) Véase también diagrama de flujo de datos, entidad externa. 

ENTIDAD ASOCIATIVA Tipo de entidad que asocia las instancias de una o más enti¬ 
dades y contiene atributos particulares para la relación entre dichas instancias. 

ENTIDAD ATRIBUTIVA Uno de los tipos de entidades utilizado en diagramas de en¬ 
tidad-relación. Algo útil en la descripción de atributos, especialmente en aquellos gru¬ 
pos de atributos que se repiten. [2] 

ENTIDAD EXTERNA Fuente o destino de datos considerados extemos para el sistema 
descrito. También se le llama entidad. (7) Véase también diagrama de flujo de datos. 

ENTORNO Cualquier cosa externa para una organización. Existen diversos entornos, 
como serían los físicos, económicos, legales y sociales. (2) 

ENTRADA Cualquier dato, sea textual o numérico, que se introduce en un sistema 
de información para ser almacenado o procesado. La introducción puede ser mediante 
formularios, pantallas, voz o formularios interactivos que se contestan en la Web. (12) 

ENTREGABLES (PRODUCTOS FINALES) El software, documentación, procedi¬ 
mientos, manuales de usuario o sesiones de capacitación que un analista de sistemas 
entrega a un cliente de acuerdo con los términos especificados en un contrato. (8) 

ESPAÑOL ESTRUCTURADO Técnica para analizar' decisiones estructuradas con base 
en lógica de estructuras e instrucciones sencillas en español, como sumar, multiplicar y 
mover. (9) 

ESTRUCTURA DE DATOS Estructuras compuestas de elementos de datos, que por 
lo general se describen mediante notación algebraica para producir una vista de los ele¬ 
mentos. El analista empieza con el diseño lógico y a continuación diseña las estructuras 
físicas de datos. (8) 

FAVTCON Pequeño icono que aparece junto a cualquier dirección marcada como 
favorita en un navegador. Al copiar al escritorio de la computadora el vínculo hacia el 
sitio favorito hace que se genere una versión más grande del icono en ese lugar. Estos 
iconos se pueden crear con un generador de iconos de Java o con otros programas para 
gráficos. (11) 

El RE WALL Software de seguridad de la computadora que se utiliza para levantar una 
barrera entre una LAN de una organización e Internet. Aunque esto evita que los 
hackers entren a la red interna, también ocasiona que los miembros de la organización 
no puedan acceder directamente a Internet. (17) 

FLUJO DE DATOS Datos que se mueven en el sistema de un lugar a otro; la entrada 
y la salida se representan usando una flecha en los diagramas de flujo de datos. (7) 

FOLKLORE Técnica de documentación de sistemas basada en métodos tradiciona¬ 
les que se utiliza en la recopilación de información de personas e historias populares 
y leyendas. (16) 

GENERADORES DE CÓDIGO Software que crea automáticamente todo o paite de 
un programa de computadora. Por lo regular, es una característica de un producto CASE 
de bajo nivel o integrado. (16) 

GRÁFICAS DE GANTT Representación gráfica de un proyecto que muestra cada ta- 
reaj o actividad, como una barra horizontal, la longitud de la cual es proporcional al 
tiempo de su terminación. (3) 

GRUPO DE REPETICIÓN La existencia de muchos de los mismos elementos en la es¬ 
tructura de datos. (8) Véase también estructura de datos. 

HERENCIA En el análisis y diseño orientado a objetos, las clases pueden tener hijos. 
La clase padre se conoce como clase base, y la clase hija como clase derivada. Al crear 
una clase derivada, ésta puede heredar todos los atributos y comportamientos de la cla¬ 
se base. (18) 
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HE RRAMIENTAS CASE Herramientas de ingeniería de software asistida por compu¬ 
tadora que incluyen capacidades automatizadas de diagramación, análisis y modela¬ 
ción. (1} Véase también herramientas CASE de bajo nivel, herramientas CASE de alto 
nivel. (1) 

HERRAMIENTAS CASE DE ALTO NIVEL Herramientas CASE diseñadas para apoyar' 
la planeación de información, así como las fases de identificación y selección de pro¬ 
yectos, inicio y planeación de proyectos, análisis y diseño del ciclo de vida del desarrollo 
de sistemas. (1) Véase también herramientas CASE, herramientas CASE de bajo nivel. 

HERRAMIENTAS CASE DE BAJO NIVEL Aquellas herramientas CASE usadas por 

analistas para producir el código fuente de la computadora, eliminando la necesidad 

de programar - el sistema. (1) Véase también herramientas CASE, herramientas CASE de 

alto nivel. 

/ 

HIPERVINCULO Palabra resaltada en un sistema de hipertexto que despliega otro 
documento cuando el usuario hace che en ella. (11) 

ICONO Imagen pequeña que representa actividades y funciones que están disponi¬ 
bles para el usuario cuando es activada, por lo regular' al hacer che sobre ella. Se utiliza 
con frecuencia en el diseño de interfaces gráficas de usuario (GUI). (14) 

IMPLEMENTACIÓN Última fase del ciclo de vida del desarrollo de sistemas, en la 
cual el analista se asegura que el sistema sea funcional y después permite a los usuarios 
tomar' control sobre su uso y evaluación. (17) 

INGENIERÍA DE SOFTWARE ASISTIDA POR COMPUTADORA (CASE) Herramientas 
de software especializadas que incluyen capacidades automatizadas de diagramación, 
anáfisis y modelación, basadas en computadora. (1) Véase también herramientas CASE 
de bajo nivel, herramientas CASE de alto nivel. 
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INGE NIE RÍA INVERSA LO opuesto a la generación de código. En esta técnica el có¬ 
digo fuente se examina, analiza y convierte en entidades de un depósito, generalmente 
de una herramienta. CASE. (1) 

INTERFAZ DE LENGUAJE DE COMANDOS Tipo de interfaz que permite a los usua¬ 
rios controlar' la aphcación mediante combinaciones de teclas, comandos, frases o alguna 
secuencia de estos tres métodos. (14) 

INTERFAZ DE LENGUAJE NATURAL Interfaz que permite al usuario hablar' o escri¬ 
bir en lenguaje humano para interactuar' con la computadora. (14) 

INTERFAZ DE LLENADO DE FORMULARIO Parte de los elementos de diseño de una 
GUI que pide automáticamente al usuario el llenado de un formulario estándar'. Muy 
útil para las aplicaciones de comercio electrónico. (14) 

INTERFAZ GRÁFICA DE USUARIO (GUI) Interfaz de usuario basada en iconos, con ca¬ 
racterísticas tales como nrenús descendentes, hstas desplegables y botones de opción. (14) 

JAVA Lenguaje de programación orientado a objetos que permite ejecutar' aplicacio¬ 
nes dinámicas en Internet. (11) 

LENGUAJE UNIFICADO DE MODELACIÓN (UML) UML ofrece un conjunto están- 
darizado de herramientas para documentar' el anáfisis y diseño orientado a objetos de 
un sistema de software. (18) 

LÍNEA DIGITAL DE SUSCRIPTOR (DSL) Protocolos que permiten la transmisión de 
datos a alta velocidad en un cable telefónico común. (17) 

LISTA DESPLEGABLE Uno de los diversos elementos de una interfaz gráfica de 
usuario (GUI), mediante el cual el usuario puede hacer clic en un cuadro que simu¬ 
la extenderse hacia abajo en la pantalla y presentar varias alternativas, mismas que pue¬ 
den seleccionarse a continuación. (11) 

MANTENIMIENTO En esta fase del ciclo de vida del desarrollo de sistemas (SDLC) 
se reparan los problemas que se detectan. Esto continúa durante la vida del sistema. 
Una parte del mantenimiento se puede hacer automáticamente al conectarse al sitio 
Web del fabricante. (1) 




MENÚ DESCENDENTE Uno de los diversos elementos de diseño de una GUI que 
proporciona un menú de opciones en la pantalla cuando el usuario selecciona el nom¬ 
bre del comando en una barra de menús. (14) 

METODO En UML, un método es una acción que puede ser solicitada por cualquier 
objeto de la clase. Los métodos son procesos que una clase sabe cómo llevar' a cabo. (18} 

METODOLOGÍA DE DESARROLLO DE SISTEMAS Cualquier enfoque aceptado para 
analizar', diseñar', implementar, probar, mantener y evaluar' un sistema de información. 
(1) Véase también ciclo de vida del desarrollo de sistemas. 

MINERIA DE DATOS Técnicas que emplean algoritmos para la extracción de patrones 
de datos que se encuentran en almacenes de datos y que por lo general no son eviden¬ 
tes para los humanos encargados de la toma de decisiones. Este concepto también se 
conoce como descubrimiento de datos para el conocimiento (KDD). (14} 

MODELACIÓN ÁGIL Método de desarrollo de sistemas similar' a la programación ex¬ 
trema, que tiene valores, principios y prácticas útiles para los analistas de sistemas. (6} 

MODELO DE BASE DE DATOS RELAQONAL Representa los datos de una base de 
datos en forma de tablas bidimensionales conocidas como relaciones. Siempre y cuando 
ambas tablas compartan un elemento de datos común, la base de datos puede relacio¬ 
nar' cualquier archivo o tabla con los datos de otro archivo o tabla. (13) 

MUESTREO Proceso consistente en la selección sistemática de elementos represen¬ 
tativos de una población. Los analistas muestrean datos puros, datos almacenados en 
archivos y usuarios durante la determinación de requerimientos de información. (5) 

NAVEGADOR Software especial que se ejecuta en una computadora conectada a 
Internet, mediante el cual los usuarios pueden ver páginas Web basadas en hipertexto. 
Ejemplos de navegadores gráficos son Microsoft Internet Explorer y Netscape Com- 
municator. (11) 

NORMALIZACIÓN Transformación de las vistas de usuario y almacenes de datos com¬ 
plejos en un conjunto de estructuras de datos más pequeñas y estables. Es más sencillo 
dar - mantenimiento a las estructuras de datos normalizadas que a las complejas. (13) 

OBJETO En el enfoque orientado a objetos, un objeto es una representación en compu¬ 
tadora de algún evento o cosa del mundo real. Los objetos pueden tener atributos y 
comportamientos. (18) 

OBSERVACIÓN ESTRUCTURADA DEL ENTORNO (STROBE) Método de obser¬ 
vación sistemático para clasificar' e interpretar los elementos de la organización que 
influyen en la toma de decisiones. La técnica se basa en una técnica de crítica de cine 
llamada mise-en-scéne. (5) 

ORGANIZACIÓN DE ARCHIVOS INDEXADOS Tipo de organización de archivos que 
utiliza archivos de índice separados para localizar' registres. (13) 

PANTALLA Cualquiera de las diversas alternativas de dispositivos de despliegue que 
emplean los usuarios para visualizar' el software de cómputo, entre ellas los monitores y 
los dispositivos de plasma líquido. (11) 

PAQUETE En UML, los elementos se agrupan en paquetes. Éstos se pueden considerar' 
como subsistemas físicos. Los sistemas se implementan y distribuyen en paquetes. (18) 

PENSAR EN OBJETOS Declaraciones elementales que el analista escribe en tarjetas 
CRC con el propósito de empezar' a pensar de una forma orientada a objetos. (18) 

PLUG-SN (complemento) Pequeño programa que complementa las funciones de 
una aplicación original. Algunos plug-ins permiten utilizar' las características especiales 
con que cuentan algunos sitios Web multimedia. Entre los ejemplos se encuentran 
Shockwave para Netscape Navigator y RealAudio para Internet Explorer. (11) 

POLIMORFISMO En los enfoques orientados a objetos, se refiere a los comporta¬ 
mientos alternativos de las clases derivadas. Cuando las clases derivadas heredan atri¬ 
butos y comportamientos, el comportamiento de una clase derivada podría diferir del 
de su clase base o de sus clases hermanas. (18) 




PREGUNTA ABIERTA Tipo de pregunta usada en entrevistas o en encuestas que 
permite una amplia gama de respuestas. (4) Véase también pregunta bipolar - , pregunta 
cerrada. 

PREGUNTA BIPOLAR Subconjunto de preguntas cerradas que tienen sólo dos res¬ 
puestas posibles, como sí o no, falso o verdadero y acuerdo o desacuerdo. (4) Véase tam¬ 
bién pregunta cerrada, pregunta abierta. 

PREGUNTA CERRADA Tipo de pregunta utilizada en entrevistas o en encuestas que 
limita el conjunto de respuestas posibles disponibles para responder. (4] Véase también 
pregunta bipolar, pregunta abierta. 

PRI ME RA FORMA NORMAL (1 NF) Primer paso en la normalización de una rela¬ 
ción de datos utilizado en una base de datos, con el propósito de eliminar los grupos 
que se repiten. (13} Véase también segunda forma normal, tercera forma normal. 

PROCESAMIENTO POR LOTES Procesamiento de datos que se encuentran almace¬ 
nados y son accesados directamente por la computadora, sin requerir la intervención 
de personas. Se utiliza para procesar grandes cantidades de datos. (7) 

PROCESO Las actividades que transforman o cambian datos en un sistema de infor¬ 
mación. Pueden ser manuales o automatizados. Se denotan mediante un rectángulo re¬ 
dondeado en los diagramas de flujo de datos. (2) 

PROGRAMACIÓN EN PAREJAS Práctica elemental de programación extrema en la 
cual dos programadores que deciden trabajar conjuntamente, realizan la programación, 
ejecutan las pruebas y discuten las opciones para concretar el trabajo de la manera más 
eficaz y eficiente. (3) 

PROGRAMACIÓN EXTREMA (XP) La programación extrema (XP) es un enfoque 
de desarrollo de sistemas que acepta lo que conocemos como prácticas buenas de de¬ 
sarrollo de sistemas y las lleva al extremo. Entre las prácticas esenciales y únicas de XP 
están la liberación limitada, la semana de trabajo de 40 horas, cliente en el sitio y pro¬ 
gramación en parejas. (3) 

PROPUESTA DE SISTEMAS Propuesta escrita que sintetiza el trabajo del analista 
de sistemas en la empresa e incluye recomendaciones y alternativas para solucionar - los 
problemas identificados en los sistemas. (10) 

PROVEEDOR DE SERVICIOS DE APLICACIONES (ASP) Compañía que aloja 
software de aplicaciones, el cual es rentado por otras organizaciones para usarlo a través 
de la Web. Entre las aplicaciones se encuentran las tradicionales, además de las de co¬ 
laboración y de administración de datos. (10) 

PROVEEDOR DE SERVICIOS DE INTERNET (ISP) Compañía que proporciona, 
mediante una cuota, acceso a Internet y posiblemente a otros servicios, como aloja¬ 
miento de páginas Web y análisis de tráfico. (12) 

PRUEBA DE SISTEMAS La sexta fase del SDLC Qunto con el mantenimiento). Uti¬ 
liza tanto datos de prueba como datos reales para identificar - los errores, la prontitud, la 
facilidad de uso, la clasificación adecuada de las transacciones, el tiempo inactivo acep¬ 
table, la comprensión de los manuales de procedimientos, así como otros aspectos del 
nuevo sistema. (16) 

PSEUDOCÓDIGO Técnica para generar - instrucciones de computadora que constituyen 
un paso intermedio entre el lenguaje natural y el código de un programa. Se utiliza para 
representar - la lógica de cada módulo en un diagrama de estructura. (16) Véase también 
diagrama de estructura. 

RED DE ÁREA LOCAL (LAN) El cableado, hardware y software usado para conectar 
estaciones de trabajo, computadoras y servidores de archivos ubicados en un área geo¬ 
gráfica limitada (por lo general dentro de un edificio o una universidad). (15) 

RED DE SERVICIOS DIGITALES INTEGRADOS (ISDN) Servicio de red conmutado 
que provee conectividad digital de extremo a extremo para la transmisión, en una sola 
línea, de voz, datos y vídeo simultáneamente. (17) 







REGISTRO Colección de elementos de datos que comparten una característica co¬ 
mún con la entidad descrita. (13) 

REGLAS DEL NEGOCIO Declaraciones, específicas para el funcionamiento de una 
organización, que proporcionan una descripción lógica de las actividades del negocio. 
Se utilizan en la creación de diagramas de flujo de datos. (7} 

REINGEN1ERIA En general, consiste en rediseñar la forma de hacer el trabajo y en se¬ 
leccionar' las herramientas de cómputo para apoyar el proceso rediseñado. El término 
tiene connotaciones diferentes en los contextos de ingeniería, programación y negocios. 

RELACIÓN Asociaciones entre entidades (llamadas en ocasiones asociaciones de da¬ 
tos) . Estas asociaciones pueden ser de la forma uno a uno, uno a muchos, muchos a uno 
o muchos a muchos. (13) 

REPASO ESTRUCTURADO Revisión hecha por colegas, en forma sistemática, de la 
programación de un sistema y de su desarrollo en general. Esto resalta los problemas y 
permite al programador o al analista realizar los cambios correspondientes. (16) 

RUTA CRETICA La ruta más larga calculada utilizando la técnica de diagramas PERT. 
Es la ruta que provocará que el proyecto total se retrase si se encuentra en ella incluso 
un solo día de atraso. (3) 

SALIDA Información distribuida a los usuarios mediante los sistemas de información, 
a través de intranets, extrañéis o la Web, ya searén informes impresos, pantallas o audio. 

SEGUNDA FORMA NORMAL (2NF) Al normalizar datos para una base de datos, el 
analista se asegura que todos los atributos que no sean claves dependan totalmente de 
la clave primaria. Todas las dependencias parciales se eliminan y colocan en otra rela¬ 
ción. (13) Véase también primera forma normal, tercera forma normal. 

SEIS SIGMA Consiste en una cultura enfocada a la calidad. La meta de Seis Sigma es 
eliminar todos los defectos. (16) 

SISTEMA Colección de subsistemas interrelacionados e interdependientes, que tra¬ 
bajan de manera conjunta para llevar' a cabo metas y objetivos predeterminados. Todos 
los sistemas cuentan con entradas, procesos, sahdas y retroalimentación. Un sistema de 
información constituye un ejemplo; una organización es otro ejemplo. (2) Véase tam¬ 
bién sistema cerrado, sistema abierto. 

SISTEMA ABIERTO Parte de la teoría general de sistemas; un sistema que, sin restric¬ 
ciones, recibe como entrada información, energía, usuarios o materia prima. Los sistemas 
nunca son totalmente abiertos o cerrados, sino que van de más cerrados a más abiertos. 
(2) Véase también sistema cerrado. 

SISTEMA CERRADO Forma parte de la teoría general de sistemas; un sistema que no 
recibe información, energía, personas o materia prima como entrada. Los sistemas nun¬ 
ca son totalmente abiertos o cerrados, sino que van de más cerrados a más abiertos. (2) 
Véase también sistema abierto. 

SISTEMA DE ADMINISTRACIÓN DE BASE DE DATOS (DBMS) Software que or¬ 
ganiza los datos de una base de datos proporcionando capacidades de almacenamiento, 
organización y recuperación de información. (13) 

SISTEMA DE APOYO A EJECUTIVOS (ESS) Sistema de cómputo que ayuda a los 
ejecutivos a organizar sus interacciones con el entorno externo mediante apoyo gráfico 
y de comunicaciones. (1) 

SISTEMA DE APOYO A LA TOMA DE DECISIONES (DSS) Sistema de información 
interactivo que apoya el proceso de toma de decisiones mediante la presentación de in¬ 
formación diseñada específicamente para el enfoque de resolución de problemas y las 
necesidades de aplicaciones del encargado de la toma de decisiones. El sistema no toma 
las decisiones por el usuario. (10) 

SISTEMA DE INFORMACIÓN GERENQAL (MIS) Sistema basado en computadoras 
compuesto por personas, software, hardware y procedimientos que comparte una base de 
datos común para ayudar a los usuarios a interpretar y aplicar los datos en los negocios. (1) 




SISTEMA DE PROCESA MI ENTO DE TRANSACCIONES (TPS) Sistema de infor¬ 
mación computarizado cuyo propósito es procesar grandes cantidades de datos relacio¬ 
nados con transacciones rutinarias de negocios, como las de nómina e inventarios. (1) 

SISTEMA EXPERTO (ES) Sistema basado en computadora que captura y utiliza el 
conocimiento de un experto para resolver un problema particular. Sus componentes bá¬ 
sicos son la base de conocimientos, un motor de inferencia y la interfaz de usuario. (1) 

SISTEMAS DISTRIBUIDOS Sistemas de cómputo que se localizan en diversos pun¬ 
tos geográficos, y que también cuentan con procesamiento, datos y bases de datos dis¬ 
tribuidos. Los sistemas cliente/servidor basados en LAN constituyen una arquitectura 
común para los sistemas distribuidos. (17) 

SOFTWARE DE CÓDIGO ABIERTO Modelo de desarrollo y filosofía de distribución 
de software libre y publicación de su código fuente; los usuarios y los programadores 
tienen libertad de estudiar, compartir y modificar este código fuente. El sistema opera¬ 
tivo LINUX es un ejemplo de software de código abierto. 

SOFTWARE DE VALIDACIÓN Software que verifica si es válida la entrada de datos al 
sistema de información. A pesar de que la validación de la entrada se realiza en su ma¬ 
yor parte a través del software, que es responsabilidad del programador, corresponde al 
analista saber cuáles problemas comunes podrían invalidar una transacción. (15) 

SONDEO Preguntas de seguimiento que se utilizan primordialmente durante las entre¬ 
vistas entre analistas y usuarios. (4) Véase también pregunta cemada, pregunta abierta. 

TABLA DE DECISIONES Una forma de examinar, describir - y documental - decisiones 
estructuradas. Se trazan cuatro cuadrantes para describir las condiciones, identificar - posi¬ 
bles alternativas de decisión, indicar - cuáles se deben realizar - y describir tales acciones. (9) 

TARJETAS CRC El analista genera tarjetas de Clase, Responsabilidades y Colaborado¬ 
res para representar - las responsabilidades de las clases y la interacción entre éstas al em¬ 
pezar - a modelar - el sistema desde una perspectiva orientada a objetos. El analista genera 
las tarjetas con base en escenarios que delinean los requerimientos del sistema. (18) 

TERCERA FORMA NORMAL (3NF) En la tercera forma normal se eliminan todas las 
dependencias transitivas. Una dependencia transitiva es aquella en la cual los atributos 
que no son claves dependen de otros atributos que tampoco son claves. (13) Véase tam¬ 
bién primera forma normal, segunda forma normal. 

TIPO DE ENTIDAD Colección de entidades que comparten propiedades o caracterís¬ 
ticas comunes. (8) 

USUARIOS FIN ALES Individuos profesionales de una organización, ajenos a los de¬ 
partamentos de sistemas de información, quienes especifican los requerimientos de ne¬ 
gocios para el uso de las aplicaciones de software. Con frecuencia, los usuarios finales 
solicitan aplicaciones nuevas o modificadas, prueban y dan su consentimiento para el 
uso de las aplicaciones, y podrían fungir - como expertos de negocios en equipos de pro¬ 
yectos. (1) 

VALOR PREDETERMINADO Valor que adoptará un campo a menos que se introduz¬ 
ca un valor explícito en el mismo. (13) 

VALOR PRESENTE El valor total que tiene, en este momento, una serie de pagos fu¬ 
turos. Es un medio para evaluar - las erogaciones e ingresos económicos del sistema de 
información a lo largo de su vida útil y de comparar los costos actuales con los benefi¬ 
cios futuros. (10) 

WEBMASTER Persona encargada de actualizar - y dar - mantenimiento a un sitio Web. 
Por lo general, estas tareas corresponden al analista de sistemas durante el desarrollo de 
aplicaciones de comercio electrónico. (12) 

XP Véase programación extrema. (3) 
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usuario 

análisis de sistemas y, 7 
aseguramiento de la calidad y, 581 
capacitación, 621, 632-35 
consideraciones de la salida, 360, 368-70 
diseño de cuadros de diálogo y. 506-9 
diseño de la salida y, 414 
elaboración de prototipos y, 159-60 
herramientas CASE y, 15 
historias de usuarios, 172-74, 177 
prueba y, 606 

retroalimentación para. 510-14 
SDLCy, 11 

sesgo de la salida y, 373-74 
vistas de datos y, 444 
Utilidad 

de actualización, 643-44 
de formularios, 643-44 
de lugar, 643-44 
de objetivo, 643-44 
de posesión, 643-44 
de tiempo, 643-44 
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Valentía (valor de XP), 166-67 
Validación 

calidad de entrada de datos y, 543, 560-66 
de cuestionarios, 106-7 
elementos de datos y, 255 
proceso de, 566, 566/ 

Valores predeterminados, 507 
VBUnit, 175 

Verificación de errores, 197-99 
Vestimenta de los tomadores de decisiones, 

42, 137, 139 
Viabilidad 

definición de objetivos, 53-55 
determinación. 52, 57 
económica, 54/-55/ 55 
operativa, 55-56, 56/ 
recursos y, 55-56 
técnica, 55-56, 56/ 

Vídeo inverso, 417 

Vinculación e Incrustación de Objetos (OLE), 
588 

Visible Analyst (VA), 15, 17, 70, 255-56, 284, 
286, 287/ 626, 680 
Visitantes diferentes, 646 
Visitas, 646 
Vista física, 454-55 
Vistas 

de usuario, 262, 459 
lógicas, 454-55 
múltiples, 20 
Visual C++, 163 
Visual Intercept, 175 
Visual Source Safe, 175 
VisualAge (IBM), 175 
VPNs (redes privadas virtuales), 640 
VRML (Lenguaje de Marcado de Realidad 
Virtual), 380/ 
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WAN (red de áiea amplia], 624 
Webmaster, 380/, 383 
Webtrends, 645 

WEP (privacidad equivalente al cableado], 
625-26 

Wheat First Securities, 368 
Whiteboard, 175 
Wi-Fi (fidelidad inalámbrica] 
como sistema distribuido, 625 
consideraciones de salida, 372 
consideraciones de uso, 368 
diseño de sistemas y, 6 
PC de tableta y, 504 
WEP y, 626 
WikiWiki, 175 

Windows for Workgroups, 631 


Windows NT, 631 

WLAN (red de área local inalámbrica], 6, 
372, 625 

Woody's Window Watch, 367 
WOPR Placebar Customizer, 424 
WordPerfect Corporation, 67 
World Wide Web [WWW], Véase también 
Internet 

aplicación de cuestionarios, 109-11 
aplicaciones de comercio electrónico y, 4-5 
aplicaciones ERP y, 32 
búsqueda, 524-25 

consideraciones de seguridad, 637-41 
definición, 380/ 
diseño de salida y, 360 
GUI y, 503 

publicación de bases de datos en, 479-81 
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recopilación de infomiación de, 330-31 
salida y, 359 

tecnología de actualización automática, 
367-68 

tecnología de demanda, 366-67 
WYSIWYG, 375 
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XML. Véase Lenguaje de Marcación 
Extensible 

XP. Véase Programación extrema 
XSLT (Transformaciones del lenguaje de hojas 
de estilo extensibles], 387-88 
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